This is the mail archive of the
mailing list for the binutils project.
Re: the way ld evaluates and chooses libraries
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.