Very Computer

I've been setting up a C++ development environment for several
programmers,
and we have our application divided into multiple sub-projects.  Each of
these sub-projects, usually one GUI screen, is located in its own
directory.
This is all on UNIX (Sun), using SCCS for configuration management.

Each subproject is developed independently from the others, and each
of these subprojects has its own static library.  Consequently, we have
quite a few files such as libScreenA.a, libScreenB.a, etc...

The directory structure has a "master" makefile, which links all of
these
library files into one executable.  The whole system is working very
well for us, however I am concerned about the size of the resulting
program.  It is around 5.5 MB now, although it does include debugging
info still.

Would the resulting executable be smaller if we didn't build it from
multiple libraries?  If libraries are interdependent, we sometimes have
to list them two or three times in the LIBS section of the makefile...
does this cause extra code to be inserted into the executable, as well?

Any insight would be appreciated!
--
...
...  Eric M. Burke                 -  C++

...  http://www.i1.net/~ericb/     -  HTML
...  314-895-6250
...

 . . . snip . . .

Quote:

> Each subproject is developed independently from the others, and each
> of these subprojects has its own static library.  Consequently, we have
> quite a few files such as libScreenA.a, libScreenB.a, etc...

Quote:

> The directory structure has a "master" makefile, which links all of
> these
> library files into one executable.  The whole system is working very
> well for us, however I am concerned about the size of the resulting
> program.  It is around 5.5 MB now, although it does include debugging
> info still.

Quote:

> Would the resulting executable be smaller if we didn't build it from
> multiple libraries?  If libraries are interdependent, we sometimes have
> to list them two or three times in the LIBS section of the makefile...
> does this cause extra code to be inserted into the executable, as well?

--

   Opinions mine, not my employer's except by most bizarre coincidence.

: I've been setting up a C++ development environment for several
: programmers,
: and we have our application divided into multiple sub-projects.  Each of
: these sub-projects, usually one GUI screen, is located in its own
: directory.
: This is all on UNIX (Sun), using SCCS for configuration management.

: Each subproject is developed independently from the others, and each
: of these subprojects has its own static library.  Consequently, we have
: quite a few files such as libScreenA.a, libScreenB.a, etc...

Sounds a good way of doing it. We do much the same thing, usually have
a library for each directory of source code. We have had programs linked
from about 50 libraries on occasions.

: The directory structure has a "master" makefile, which links all of
: these
: library files into one executable.  The whole system is working very
: well for us, however I am concerned about the size of the resulting
: program.  It is around 5.5 MB now, although it does include debugging
: info still.

Use size command, or try stipping the executable to see how much is debug
information and how much is code. You also need to add an estimate for
dynamic memory usage to get an idea of the memory needed at run time.

: Would the resulting executable be smaller if we didn't build it from
: multiple libraries?  If libraries are interdependent, we sometimes have
: to list them two or three times in the LIBS section of the makefile...
: does this cause extra code to be inserted into the executable, as well?

No, ld only should pull any object in once so the size will be the same.
We have done this alot and never had problems. See what map file options
your linker offers so you can see what code is pulled in (Probably -m.)
You might also investigate if you ld has the -y <symbol> option to trace
specific symbols.

If you wish to reduce repetitions of libraries to improve link speed
look at the lorder command or using the -u <symbol> switch to the linker.
Excesive use of -u can result in maintenace problems so be selective.

If you have an extreamly large program you might be able to improve performance
by carefull ordering of the object files in the image (by controling the
ordering they are linked) to reduce paging. However unix does not offer many
tools to help decide and obtain a good order or so I would not try doing
anything unless you have real problems. Even then a better solution would be to
consider if you really need one integrated application or if you can spawn sub
applications from another.

--

Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom
 Are you using ISO8859-1? Do you see ? as copyright, as division and ? as 1/2?

Quote:>I've been setting up a C++ development environment for several
>programmers,
[...]
>The whole system is working very
>well for us, however I am concerned about the size of the resulting
>program.  It is around 5.5 MB now, although it does include debugging
>info still.
[...]
>Would the resulting executable be smaller if we didn't build it from
>multiple libraries?  If libraries are interdependent, we sometimes have
>to list them two or three times in the LIBS section of the makefile...
>does this cause extra code to be inserted into the executable, as well?

A .a library is just an archive similar to a tar file that contains
all the .o files that make up the library, and an index file. If you use
ar tv libfoo.a it'll list them all. *All* these libraries do is provide
a useful short-cut to the user so that he doesn't have to put several
hundred .o files on the command line.

The linker will check all the .o files provided for interdependency and
only include those that are used. Some (broken) linkers will only look
inside .a files once, requiring you to put them on the command line
more than once, but they won't include the same .o file in the executable
more than once.

A 5.5 MB executable including debugging information is all right for a
large project. I did a project that gave me a 2 MB executable once;
after stripping out debug info it dropped to ~200kB. Try stripping it
and seeing what happens.

The other cause for large executables is using static libraries rather
than dynamic ones. If you have ldd on your system, try running it on
your executable to see what dynamic libraries it needs. Usual culprits
are Motif (libXm.so) and C++ runtime libraries, which tend not to be
installed properly. Motif will bloat your executable by a couple of meg
and the C++ runtime is the source of the infamous 500kB `Hello world'
program the old versions of gcc produced.

--
------------------- http://www-hons-cs.cs.st-and.ac.uk/~dg --------------------
   If you're up against someone more intelligent than you are, do something
    totally insane and let him think himself to death.  --- Pyanfar Chanur
---------------- Sun-Earther David Daton Given of Lochcarron ------------------

Quote:>*All* these libraries do is provide a useful short-cut to the user so
>that he doesn't have to put several hundred .o files on the command line.

Quote:>Some (broken) linkers will only look inside .a files once, requiring you
>to put them on the command line more than once, [..]

: >Some (broken) linkers will only look inside .a files once, requiring you
: >to put them on the command line more than once, [..]

: I wouldn't consider such linkers to be broken, that's perfectly normal
: behaviour for a UNIX linker. If you need to put a library on the command
: line more than once, it's a very strong indication that you have a
: serious problem in your program/library hierarchy.

It's a feature, not a bug.  Consider:

cc buggy.o -ldebuglib otherstuff.o -lnormallib

Where debuglib and normallib define different versions of the same
functions.  buggy.o will use hte debug versions, which the rest will
use the normal versions.

If you 'fix' my linker so that this doesn't work I'll be very unhappy.
To avoid problems under normal circumstances, you only need to follow
one simple rule: always put libraries last on the line.  Unless, of
course, you have libraries that need symbols from other libraries,
which is a bad idea anyway.

---------------------------------------------------------------------------
Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
Electron Psychologist |                for sufficiently false values of true.

----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

Quote:>It's a feature, not a bug.  Consider:

>cc buggy.o -ldebuglib otherstuff.o -lnormallib

>Where debuglib and normallib define different versions of the same
>functions.  buggy.o will use hte debug versions, which the rest will
>use the normal versions.

Quote:>If you 'fix' my linker so that this doesn't work I'll be very unhappy.

Quote:>To avoid problems under normal circumstances, you only need to follow
>one simple rule: always put libraries last on the line.  Unless, of
>course, you have libraries that need symbols from other libraries,
>which is a bad idea anyway.

"Usenet is like a herd of performing elephants with diarrhea; massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it." [Gene Spafford]

Quote:>Watch out for the AIX linker (if you haven't already met it); it breaks
>almost everyones expectations about linkers...

: one simple rule: always put libraries last on the line.  Unless, of
: course, you have libraries that need symbols from other libraries,
: which is a bad idea anyway.

Why is it a bad idea? How do you avoid it? Do you merge libc with your
own code library so you library does not need the printf symbol from libc
when you call printf? How do you handle reusing utility functions between
diffrent applications if you don't put them a library that can be used by all,
or do you not use libraries for the applications code?

--

Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom
 Are you using ISO8859-1? Do you see ? as copyright, as division and ? as 1/2?