Re: [jamboost] Boost.Build Feature request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-21 04:34:08

Puverle, Tomas (IT) wrote:

> > Hi Puverle,
>
> It's Tom :)

I'm sorry! 

> > > In our environment, we build all shared objects with all external
> > > references unresolved, so that a .so A never depends on a shared
> > > library B.
> >
> > Why?
>
> Without getting into too much detail, it helps us with library
> versioning and debugging of code.

Ok, though if you could find the time to give more details, it would be great. 
I don't insist, it's just better to know all the use cases we have to 
support.

> > What are "additional libraries"?
>
> Our STL and a few others.

How do you specify those additional libraries? With <find-library>?

> > > So the Jam link rule will perform something like this:
> > >
> > > ld ... <executable> <stl and support libs> <libboost_*>
> > >
> > > when what we really need is this:
> > >
> > > ld ... <executable> <libboost_*> <stl and support libs>
> > >
> > > That way, we end up with unresolved symbols to our STL and others.
> >
> > I'm completely lost. Unless there are some static libraries,
> > the above two command like should be exactly equivalent. The
> > linker will just add an entry for each library into the
> > final binary (either library or exe). The order will differ,
> > but that only matters if the same symbol is defined in
> > several libraries.
>
> That is not correct:
>
> <man ld>
> `-larchive'
>
> `--library=archive'
.......
> The linker will search an archive only once, at the
> location where it is specified on the command line.

I'm afraid the documentation is not correct ;-) Here's a part of email 
exchange with a binutils maintainer:

> Consider the case where "main" linkigs to "libA.so" which links to
> "libB.so". 
> The references from "libA.so" to symbols in "libB.so" will be resolved
> at runtime by dynamic linkder. Am I right in thinking that ld mimics
> the behaviour of dynamic linkder to make sure unresolved symbols don't
> occur at runtime?
>
> Which means I have two choices: 
<snip> 
> Is that so?

Yes - this is exactly correct.

I also attach a testcase which shows that for shared libraries, the order 
difference in order does not cause link errors. So, I stand by my original 
statement -- the order matters only if you have static libraries in the link.

> So what that means is that if I have a command line like this:
>
> ld exec libA libB
>
> and libB references libA, you will get unresolved symbol errors, however
>
> ld exec libB libA
>
> will link.
>
> > I think you need to clarify what you want.
>
> Does that make sense?

Assuming there are static libraries, I can interpret your problem like this:

1. You build Boost.Test such that it refers to your STL
2. In the final link line Boost.Test is after STL
3. The STL library (or some of the libraries) are static.

The result is that reference from Boost.Test to STL is not resolved.

For V2, the libraries specified via <find-library> are at the end of command 
line already, so that should fix your case. Besides, there are other 
mechanism for controlling library order.

But I presume you're using V1. We need a bit more details. If you specify STL 
libraries via <find-library> they should end up in "-l" options at the end of 
the command line. What the method do you use? <library-file>?

- Volodya

 --Boundary-00=_QW/TBAvEskaAsE5 Content-Type: application/x-tgz;
name="libs.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="libs.tar.gz"

[Attachment content not displayed.] --Boundary-00=_QW/TBAvEskaAsE5--