Re: [jamboost] Boost.Build Feature request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-20 08:42:39

Hi Puverle,

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

> The symbols get only resolved once the final executable is linked. 

Strictly speaking, this is not correct. With dynamic linking, symbols are 
resolved at runtime. During linking, the linker mimics the algorithm used by 
the dynamic linker at runtime to catch any underfined symbols, but the 
libraries/symbols at runtime might be different.

> This causes us problems with boost when building the regression tests,
> as the final Jam link rule adds all additional libraries *before* the
> final libboost_*.

What are "additional libraries"?

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

> Is there any way in which this requirement could be incorporated into
> Boost.Build? I guess a simple solution would be to have another
> variable called e.g. ADDITIONAL_LIBS_LAST which would be passed as the
> last thing on linker line in the link rule.

I think you need to clarify what you want.

- Volodya

- Volodya