On Tue, Jun 2, 2009 at 9:18 AM, Wayne Uroda <[email protected]> wrote:
> I meant to say "I am unclear myself what happens when library A needs
> library B and vice-versa". Then I wonder if the order matters?
At each point in the link the linker has a list of requested external
symbols. Each library is scanned for those symbols;
if it doesn't provide any, it ends up being ignored. In your case, yes the
order matters, Observe:
cat > bar.c
bar(){foo();}
cat > foo.c
foo(){bar();}
cat >test.c
main(){foo();}
gcc -c foo.c bar.c
ar qcv libfoo.a foo.o
ar qcv libbar.a bar.o
So, we've created two libraries, calling each other. Now, linking the wrong
way doesn't work:
gcc -o test test.c -L. -lbar -lfoo
./libfoo.a(foo.o): In function `foo':
foo.c:(.text+0x7): undefined reference to `bar'
collect2: ld returned 1 exit status
but the other way works:
gcc -o test test.c -L. -lfoo -lbar
In other words, you must place them so that the first one will contain
symbols requested by previous code (foo() call in main(), defined in
libfoo.a). Linking in modules from libfoo will place a request for symbol
bar() on the list, so that by the time libbar is scanned, they will be
pulled in too. If you put libbar first though, it'll be ignored, and then
libfoo will satisfy the original reference to foo() but it'll be too late to
get bar() from libbar.
Theoretically, the linker could be doing two passes and remember all symbols
from all libraries, but the current behavior is faster and actually useful
if you have multiply defined symbols---you can juggle them by this explicit
order
mechanism.
