Re: Status of gcc library ordering?

From: Zbynek Winkler (zwin_at_[hidden])
Date: 2004-03-16 03:39:44

Christopher Currie wrote:
>>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? 

D:\>ld --version
GNU ld version 2.15.90 20040222
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.

on WinXP with mingw

> 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.)

Ok, sorry for accusing gcc :-).

> 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.

Hmm. So in my case there is no difference since I have no dead code. But 
anyway - you are saying that in order to eliminate dead code from an 
application you have to first link all the objects into a static library and 
then create the executable from this library? That's weird. I've never delved 
into the implementation of these tools... Does the linker pick from the 
library individual symbols (functions?) or whole objects?

> 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.

I believe that the mingw linker suffers the same problem :(

Zbynek

-- 
http://zw.matfyz.cz/ http://robotika.cz/
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic