Boost logo

Boost-Build :

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.


> 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

> 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


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