Boost logo

Boost-Build :

Subject: [Boost-build] library_order failures
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2016-02-04 03:00:13

I've looked into failures of the library_order test, and arrived at this failing command

     $ g++ -o main main.o -Wl,--start-group libc.a -Wl,--end-group
     libc.a(c.o): In function `c()':
     /tmp/tmpSiuzvi/c.cpp:2: undefined reference to `d()'

In this example, each of the libraries has a single function whose name matches library name,
and there's a call chain of main->a->b->c->d.

I can make this work like so:

     $ g++ -o main main.o -Wl,--no-as-needed -Wl,--start-group libc.a -Wl,--end-group

What happens, apparently is that:

- ld now has --as-needed option as default, which makes the final executable not refer to shared
   libraries that are included on the command line, but not needed.
- Whether the library is needed is determined by checking whether it provides any symbols that
   are unresolved at this point in the command line, similarly to how static linking works
- While start-group/end-group fixes order dependency for static libraries, it does not appear to
   do so for shared libraries.

So, for the original command line, the linker sees, notes that it does not export any
previously unresolved symbol, and skips that library completely. By the time it arrives at
libc.a and sees unresolved reference to 'd', is already thrown away.

I can solve this in two ways:

- Just stick "-Wl,--no-as-needed" at the start of the command line
- Re-enable automatic sorting of libraries on the command line. That's how Boost.Build
   worked before, until I decided that --start-group/--end-group is fast enough and
   we don't need to bother.


Vladimir Prus

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