Thanks for that, most interesting.
Do you know if the linker applies this behaviour to .c and .o files as well? Or just files linked using -l ? - Wayne From: Przemek Klosowski [mailto:[email protected]] Sent: Thursday, 4 June 2009 1:14 PM To: Wayne Uroda; GCC for MSP430 - http://mspgcc.sf.net Subject: Re: [Mspgcc-users] internal error: out of range error 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.
