the way ld evaluates and chooses libraries

Nick Clifton nickc@redhat.com
Fri Oct 13 16:23:00 GMT 2006


Hi Jeremy,

> So I was wondering how did ld was selecting its libraries ? I believe
> there is a kind of optimisation : after looking to all the
> dependencies, ld tries to shorten the list of libraries to link
> against. Am I right ?
> Any pointer on documentation, etc would be appreciated.

The linker searches directories containing libraries in the order 
specified to it by the linker command line (via the -L switch) and in 
the linker scripts (via the SEARCH_DIR directive).  (Both of these are 
documented in the linker manual).

It also searches for libraries in the order in which they are 
encountered on the linker's command line (via the -l switch) and the 
linker scripts (via the INPUT directive).  It does not shorten the list 
of libraries, but what it does do when it encounters a library is scan 
it to see if it can resolve any of the undefined symbols it currently 
has open.  Then it forgets about the library and goes on to the next 
item on the command line or linker script.  (Unless the --start-group, 
--end-group, --whole-archive or GROUP switches/directives have been used).

It sounds as though the problem you were having was because the
.so.9.0 file was linking with libstdc++.so.5 and that this library was 
also being used to resolve all the other undefined (c++) symbols used in 
other, earlier object files and libraries.  So what you might be able to 
do is to place the libocci.so.9.0 library as the last item on the 
linker's command line and place libstdc++.so.6 before it.  That way 
libstdc++.so.6 will be used to resolve all the other c++ symbols for all 
the other object files, but because libocci.so.9.0 comes after it on the 
command line, it will not be used to resolve symbols in that library.

Cheers
   Nick




More information about the Binutils mailing list