woods@weird.com (Greg A. Woods) writes:
> As far as I can see it does not have to be true either.  The linker need
> not register all libraries listed on the command line -- only those
> libraries which have been used to resolve symbols need to be registered
> in the final binary.
> 
> [ ... ]
> 
> Specifying an uneeded library (i.e. one which is not used to resolve any
> symbols) on the link command line should not ever cause a run-time
> error if that library is not available in the run-time environment.

uh, that's simply wrong.

the problem is, you don't know what symbols are actually "needed"
until you load all the libraries at run time, unless you reach a
particular library and find that, wow, _every single one_ of your
undefined symbols has already been satisfied.  (Even then, you might
still need the library; see below.)

for instance, say you link:

	-lfoo -lbar -lbaz -lc

-lbar may be extraneous at link time, indeed may be _entirely empty_
at link time and provide nothing for the program to use.

however, it still has to be loaded and checked at run-time, because
the version available at run-time may provide some of the symbols also
provided by -lbaz and -lc.

in other words, the version of a library available at run time may be
used to override some symbols in the later libraries.


Also, even though no functions or data items in a library are directly
referenced, the side-effects of its loading may be important.
(e.g. the solaris 0@0 shared library).


Some of the above may be a little odd, but all are valid uses of
shared libraries.

In other words, if a library is specified on the
command line, or is implied by another library, you really can't know
that you don't need it.

Therefore, the linker must register all libraries mentioned on the
command line (implied libs should be brought in by runtime evaluation
of the loaded libs ... because for all you know they may change!), and
the loader must attempt to load all of them and all of the libraries
that they need.



cgd