Re: Status of gcc library ordering?

From: Christopher Currie (Christopher_at_[hidden])
Date: 2004-03-15 15:15:54

> The way I am using it right now is that I've replaced all my 'lib :... : 
> <link>static' with 'alias...'. The way I understand it is that with alias I 
> get the actual objects on the linking command line and since the objects have 
> no ordering issue my problem is solved. The objects are compiled just once in 
> either case.
> 
> BTW: I do not really understand the problem gcc linker has with static 
> libraries. The way I understand it is that *.a is just a sofisticated *.tar 
> with *.o inside and since there is no ordering problem for the *.o - why there 
> is for *.a??? IMHO the linker does all the work related to linking, right? So 
> there is the same amout of work done for linking the exe directly from objects 
> as there is for linking it from static libs, right? If this is true then it is 
> IMHO just plain bug in gcc...

Just for the record, can you tell us what platform you are on, and which 
linker you are using, specifically? GNU ld ususally doesn't have a 
problem w.r.t. static library order, so I'm liable to think you're using 
a platform linker such as Solaris ld, which is much weaker in this 
respect, in which case it's not really GCC's fault. (It wouldn't be 
GCC's fault in any case, but the fault of whichever linker you are 
using, GNU or otherwise.)

To anwser your technical questions, there are a number of things that 
are different in the way that a traditional UNIX linker processes 
archives versus objects. When object files are specified on the command 
line, all the symbols and code in that object are stored in the 
executable, but the same is not true for archives; the linker only 
imports the symbols and code it specifically needs from an archive. This 
has the advantage of making the resulting application as small as 
possible, an important advantage for static libraries that end up with 
their code copied into every application that uses them.

Because of this optimization, the linker only pulls in the symbols it 
needs *at the time it reads the library,* and if it's a one-pass linker 
like Solaris ld, it never gets a chance to go back and pick up any 
symbols that a later library might possibly need. The GNU linker, 
thankfully, has become more intelligent and will resolve library symbols 
in any order, but the demand has not been there for the Solaris linker 
to come up to modern standards.

Christopher