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

[Domenico Andreoli]

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.

> 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 didn't feel to enforce this state of things, this is why i removed
the default.

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

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.

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

> Also note that "-lboost_program_options" (and the same applies to
> *all* of the shared libraries) is documented in README.Debian.

yes, i have to update the file. sorry.

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

whether a single-thread library may be used in a multi-thread program
is only a matter of interface design. probably libz is designed in that
way, i don't know. for instance libmysqlclient is not, you have to use
libmysqlclient_r for multi-thread programs.

and all these are C libraries. expect things to be different with
C++ ones.

cheers
domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50