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

Roger Leigh rleigh at whinlatter.ukfsn.org
Sun May 20 11:32:52 UTC 2007

Mark Purcell <msp at debian.org> writes:

> On Sat, 19 May 2007, Roger Leigh wrote:
>> By removing the default, you are breaking software which used
>> "-lboost_program_options", which is going to break a lot of software.
>> It's also going to make it FTBFS in Debian.  This applies equally to
>> all of the boost library packages with -mt and -st variants.

> As the boost library tranistion causes other packages in Debian to
> FTBFS we need to ensure some level of coordination. At least I would
> recommend that the boost team email the packages who have a rdepends
> on boost libraries so we are at least aware of the issue, rather than
> just stumbling across it the next time we try to build.

Agreed.  My main issue here is because I am the upstream as well as
the Debian maintainer.  I need some way of getting the library soname
portably, but no mechanism is currently provided.

I guess for e.g. users on Windows, or proprietary software developers,
they have the "luxury" of being able to build Boost and then hard-code
these long names.  But as free software developers we need a reliable
mechanism for detection of the Boost libraries.

> This change caused one of my packages, twinkle to FTBFS.
> As my upstream is checking for -lboost_regex and I gather twinkle should now be
> checking for -lboost_regex-{m,s}t.

> For twinkle, I can change configure to check for -lboost_regex-mt, but only 
> now that I'm aware of the issue.

I, and I think anyone else using Boost on Debian (or GNU in general),
will be running into the same issues.  I think that if we are to

- keep the same library names for compatibility with upstream and
  other OSes
- allow detection of the correct library names for source packages
- allow integration with autoconf and other build systems

then pkg-config is the most obvious (if not only) viable approach to
do this cleanly and simply.  This would allow the use of
PKG_CHECK_MODULES to check for any of the Boost libraries, e.g.


which would define BOOST_REGEX_MT_CFLAGS and BOOST_REGEX_MT_LIBS for
use in configure and Makefiles.  That would suit me nicely, and I
suspect would satisfy the requirements of most Boost-using free
software projects.

For someone familiar with bjam (I confess, I am not at all),
generating the pkg-config templates is not a hard task.  For a simple
example, schroot does this.  The gutenprint source package also does
this, albeit in a rather more convoluted fashion.  As an example:

---- boost-regex-mt.pc ----

Name: boost-regex-mt
Description: Boost C++ Regular Expression Library (multi-threaded)
Version: 1.34.0
Libs: -L${libdir} -lboost_regex-gcc41-mt-1_34
Libs.private: -licui18n -licuuc -lrt -lm
Cflags: -I${includedir} -pthread
---- boost-regex-mt.pc ----

You can generate this from a template:

---- boost-regex-mt.pc ----

Name: boost-regex-mt
Description: Boost Regular Expression Library (multi-threaded)
Version: VERSION
Libs: -L${libdir} LIBRARY_NAME
Libs.private: LIBRARY_DEPENDENCIES [for static linking]
---- boost-regex-mt.pc ----

where the capitalised names are where you would substitute in the
system- and compiler-specific options.

I don't know how bjam works, but I do this with autoconf as a file
generated by config.status, but it could also be generated by make
with a simple sed command.  I guess you could do the bjam equivalent,
whatever that might be.


  .''`.  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/20070520/e4715c2b/attachment.pgp 

More information about the pkg-boost-devel mailing list