Boost logo

Boost-Build :

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.



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at