[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