On 04/11/2012 09:54 PM, eles wrote:
if you tried to link:
gcc my_program.o -lB -lA (so, in reverse order)
read:
gcc my_program.o -lB -lA (so, in unnatural order)
this looked a bit like:
gcc my_program.o -lA -lB
read:
"it looked like the order is arbitrary"
BUT what really happened was that the true link command was now:
gcc my_program.o -lA -lB -lC -lB
read:
gcc my_program.o -lB -lA -lB -lC (so that the symbols of libA *were*
resolved)
where the "-lA -lB -lC" is the expansion of the previous "-lA".
And to tell ld to not depend on the order in which the libs are
specifies, you can use --start-group and --end-group.
From the ld man page:
--start-group archives --end-group
The archives should be a list of archive files. They may be either
explicit file names, or -l options.
The specified archives are searched repeatedly until no new
undefined references are created. Normally, an archive is searched
only once in the order that it is specified on the command line.
If a symbol in that archive is needed to resolve an undefined
symbol referred to by an object in an archive that appears later on
the command line, the linker would not be able to resolve that
reference. By grouping the archives, they all be searched
repeatedly until all possible references are resolved.
Using this option has a significant performance cost. It is best
to use it only when there are unavoidable circular references
between two or more archives.
--
Mike Wey
