[pkg-boost-devel] Bug#424038: Bug#424038: Bug#424038: Bug#424038: /usr/bin/ld: cannot find -lboost_program_options

Roger Leigh rleigh at whinlatter.ukfsn.org
Sat May 19 17:01:08 UTC 2007


Domenico Andreoli <cavok at debian.org> writes:

> On Sat, May 19, 2007 at 12:24:02PM +0100, Roger Leigh wrote:
>> Hi,
>
> hi,
>
>> [./configure ...]
>> checking for boost::program_options::variables_map in -lboost_program_options... no
>> configure: error: libboost_program_options (Boost C++ Libraries) is not installed, but is required by schroot
>> See `config.log' for more details.
>
> this check is broken, it must be fixed. it is not portable.

I would be interested to see how to make it portable.  I did a build
of the upstream source to see, and I get:

% ls libboost_program_options*
libboost_program_options-gcc41-1_34.a
libboost_program_options-gcc41-1_34.so
libboost_program_options-gcc41-1_34.so.1.34.0
libboost_program_options-gcc41.a
libboost_program_options-gcc41-d-1_34.a
libboost_program_options-gcc41-d-1_34.so
libboost_program_options-gcc41-d-1_34.so.1.34.0
libboost_program_options-gcc41-d.a
libboost_program_options-gcc41-d.so
libboost_program_options-gcc41-mt-1_34.a
libboost_program_options-gcc41-mt-1_34.so
libboost_program_options-gcc41-mt-1_34.so.1.34.0
libboost_program_options-gcc41-mt.a
libboost_program_options-gcc41-mt-d-1_34.a
libboost_program_options-gcc41-mt-d-1_34.so
libboost_program_options-gcc41-mt-d-1_34.so.1.34.0
libboost_program_options-gcc41-mt-d.a
libboost_program_options-gcc41-mt-d.so
libboost_program_options-gcc41-mt.so
libboost_program_options-gcc41.so

This is awful.  While I might be able to hard-code the "-mt" or "-st"
suffix in the check, having the compiler name in there is nasty--I
don't even know what compiler will be used, let alone know what the
Boost abbreviation for it will be.

I really don't see the need to embed the compiler name into the
library, and the -d variants are even worse!

This is really another bug report to file, but could I suggest:

- Don't package the -d variants in libboost-dbg.  200M for a debug
  package is too big.  Can't you build with debugging symbols and then
  strip them and just package the detached symbols (dh_strip does this
  now).  This would provide the same debugging symbols, but
  - takes up vastly less space
  - the symbols get used automatically by gdb
  - you link against the same library name

- Dropping the '-gcc41' suffix.

- Dropping all of the .a libraries.  Static libraries are pretty
  useless on a modern GNU/Linux system, and just take up space.

I think upstream's practice of providing four variants of the same
library (st/mt and debug/release) is not good practice, at least on
GNU/Linux.  Would it be possible to bring up these issues with
upstream?

>> If in doubt, please keep the -mt variant as the default since it was
>> already working.  As a single-threaded programmer, I don't particularly
>> care about the pthread dependency, and can't really see the need for
>> two variants of the same library so long as the mt variant works for
>> single-threaded programs.
>
> do not assume -mt variant is safe for single-thread programs, it is at
> least sub-optimal. c++ compiler does great instrumentation in order to
> make exceptions do not mess with multiple threads. i'm not sure about
> what happens to the ABI with this regard.

I took a look with "nm -C", and apart from different addresses,
there's no difference.

> i didn't feel to enforce this state of things, this is why i removed
> the default.

If Debian is not doing things the standard way, it's reasonable to
remove it.  But, would it be possible to ask upstream to add it back?

>> Is the -mt and -st suffix a Debian-specific change, or is this what
>> upstream does?  It's equally important that boost-using software on
>
> -lboost_program_options was debian specific, upstream dropped it years
> ago. also -lboost_program_options-st and -lboost_program_options-mt
> are debian specific. i added these links to hide to the final user how
> unpleasant were becoming the upstream ones.

OK.  Thanks for keeping the nicer links, but I think that it's also
important to consider backward-compatibility with Debian as well as
upstream compatibility.

> right upstream are -lboost_python-gcc41-1_34 for single-thread and
> -lboost_python-gcc41-mt-1_34 for multi-thread. they are available to
> whoever wants to use them. of course they will break at every major
> compiler revision and at every library version change (yes, even 1.34.1).
>
> help here could arrive if pkgconfig was used (bug #350539, and
> http://lists.boost.org/Archives/boost/2007/02/116513.php). other
> distribution started to develop their own .pc scripts.. but it has not
> any sense.

pkg-config would be a great solution, and should be really simple to
do, simply by creating them from a template at build-time.  I've done
this for all the libraries I have written--it's not difficult.

This should be trivial for upstream to implement.

>> Debian will also build on non-Debian systems which have the boost
>> libraries installed.  This was previously the case when using
>> "-lboost_program_options".
>
> again, i'm not so sure about how many other systems really provide
> -lboost_program_options. do you want to be sure? do you want the
> portable way of doing things? use bjam. upstream documentation describes
> bjam. whoever else told you can use -lboost_program_options and that
> it works across different systems was lying.

I just used what was existing on Debian when I wrote my own autoconf
macros to detect boost.  I can't switch wholesale to bjam for the sake
of one library dependency.  BTW, no-one "lied", but I did have
confirmation that it built on Fedora Core (6 prerelease, IIRC).

>> My program/library is currently single-threaded, but may become
>> threaded in the future.  Needing to link to a different set of
>> libraries does seem strange; after all, I don't link to an mt libc6 or
>> libz.
>
> this is because libc provides also reentrant variants of standard functions.
> multi-thread programs may use the _r variants. i.e. localtime(3).
>
> besides this kind of function, you have to build multi-thread programs
> (especially if written in c++) with -pthread, otherwise expect long
> nights with the debugger.

Of course.  However, my understanding is that the -mt form is
thread-safe, not actually creating threads, so should be perfectly
safe (if slightly less optimised) for single-threaded use.



Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-boost-devel/attachments/20070519/5d9367d2/attachment.pgp 


More information about the pkg-boost-devel mailing list