Bug#424038: [pkg-boost-devel] Bug#424038: Bug#424038: /usr/bin/ld: cannot find -lboost_program_options
severity 424038 important
thanks
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.
Roger is spot on here.. Just to add in my couple of cents worth.
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.
This change caused one of my packages, twinkle to FTBFS.
configure:20008: checking for main in -lboost_regex
configure:20037: g++ -o conftest -g -Wall -O2 -D_GNU_SOURCE
-DQT_THREAD_SUPPORT -D_REENTRANT conftest.cpp -lboost_regex -lzrtpcpp -lsp
eex -lasound -lsndfile -lresolv -L/usr/lib -lccext2 -lccgnu2 -lgnutls -lgcrypt
-lz -ldl -lrt -pthread 5
/usr/bin/ld: cannot find -lboost_regex
collect2: ld returned 1 exit status
configure:20043: $? = 1
As my upstream is checking for -lboost_regex and I gather twinkle should now be
checking for -lboost_regex-{m,s}t.
My upstream does have a FAQ entry on this
http://www.xs4all.nl/~mfnboer/twinkle/faq.html, but suggests:
Twinkle links to the libary libboost_regex.so On some systems the library is
called libboost_regex-gcc.so To solve this problem you can make a symbolic
link from libboost_regex-gcc.so to libboost_regex.so
Which is the simplest hotfix on single user machines, but not suitable
for a binary distribution.
For twinkle, I can change configure to check for -lboost_regex-mt, but only
now that I'm aware of the issue.
Mark
pgpnkrnQdxQ6u.pgp
Description: PGP signature
Bug#424038: [pkg-boost-devel] Bug#424038: Bug#424038: /usr/bin/ld: cannot find -lboost_program_options
severity 424038 important
thanks
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.
Roger is spot on here.. Just to add in my couple of cents worth.
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.
This change caused one of my packages, twinkle to FTBFS.
configure:20008: checking for main in -lboost_regex
configure:20037: g++ -o conftest -g -Wall -O2 -D_GNU_SOURCE
-DQT_THREAD_SUPPORT -D_REENTRANT conftest.cpp -lboost_regex -lzrtpcpp -lsp
eex -lasound -lsndfile -lresolv -L/usr/lib -lccext2 -lccgnu2 -lgnutls -lgcrypt
-lz -ldl -lrt -pthread 5
/usr/bin/ld: cannot find -lboost_regex
collect2: ld returned 1 exit status
configure:20043: $? = 1
As my upstream is checking for -lboost_regex and I gather twinkle should now be
checking for -lboost_regex-{m,s}t.
My upstream does have a FAQ entry on this
http://www.xs4all.nl/~mfnboer/twinkle/faq.html, but suggests:
Twinkle links to the libary libboost_regex.so On some systems the library is
called libboost_regex-gcc.so To solve this problem you can make a symbolic
link from libboost_regex-gcc.so to libboost_regex.so
Which is the simplest hotfix on single user machines, but not suitable
for a binary distribution.
For twinkle, I can change configure to check for -lboost_regex-mt, but only
now that I'm aware of the issue.
Mark
pgpya0EbtZDvz.pgp
Description: PGP signature
Bug#424038: [pkg-boost-devel] Bug#424038: Bug#424038: /usr/bin/ld: cannot find -lboost_program_options
Mark Purcell [EMAIL PROTECTED] 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.
PKG_CHECK_MODULES([boost-regex-mt])
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
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
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
prefix=PREFIX
exec_prefix=EPREFIX
libdir=LIBDIR
includedir=INCLUDEDIR
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]
Cflags: -I${includedir} THREAD_OPTIONS_FOR_COMPILER
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.
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.
pgpobs5SkO44u.pgp
Description: PGP signature
Bug#424038: [pkg-boost-devel] Bug#424038: Bug#424038: /usr/bin/ld: cannot find -lboost_program_options
On 5/20/07, Roger Leigh [EMAIL PROTECTED] wrote: 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. Actually, Windows users have the luxury of auto-linking in which only including header files is enough to get the necessary libs linked. It'd be very, very nice to get the same with gcc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424038: [pkg-boost-devel] Bug#424038: Bug#424038: /usr/bin/ld: cannot find -lboost_program_options
Hi, I'd just like to make a few observations about this bug. Firstly, its effect on one of my packages, schroot: [./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. 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. You stated in an earlier message in this bug report that I decided that there would not have been any default at all. I do feel that this is the wrong decision. I don't personally care which of the -st or -mt variants is the default, but there *must* be a default or you will break compatibility with all the boost-using software out there which is using -lboost_program_options. 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. Olaf van der Spek's comment about which variant is safest is important here, and it looks like the -mt variant is indeed the safest option, but would require someone with more threads knowledge than myself to confirm it. 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 Debian will also build on non-Debian systems which have the boost libraries installed. This was previously the case when using -lboost_program_options. Also note that -lboost_program_options (and the same applies to *all* of the shared libraries) is documented in README.Debian. 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. 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. pgpKnksIpi9rN.pgp Description: PGP signature
Bug#424038: [pkg-boost-devel] Bug#424038: Bug#424038: /usr/bin/ld: cannot find -lboost_program_options
On Tue, May 15, 2007 at 04:46:14PM +0200, Olaf van der Spek wrote: On 5/15/07, Domenico Andreoli [EMAIL PROTECTED] wrote: until 1.34.0, -lboost_program_options linked implicitly to the multi-threaded library, now you are forced to choose between single/multi thread variants. remember, debian is about choice ;-) -lboost_program_options-st - single-threaded -lboost_program_options-mt - multi-threaded Why doesn't it default to mt anymore? Because it was an arbitrary choice, it was my use of the Boost libraries. With 1.34.0 I wanted to give the right space to the needs of single-threaded users, which usually do not expect to do anything special to have their binaries not linked to libpthread. Since the default should have been the opposite, the -st variants, I decided that there would not have been any default at all. Cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424038: [pkg-boost-devel] Bug#424038: Bug#424038: /usr/bin/ld: cannot find -lboost_program_options
On 5/15/07, Domenico Andreoli [EMAIL PROTECTED] wrote: Why doesn't it default to mt anymore? Because it was an arbitrary choice, it was my use of the Boost libraries. With 1.34.0 I wanted to give the right space to the needs of single-threaded users, which usually do not expect to do anything special to have their binaries not linked to libpthread. Since the default should have been the opposite, the -st variants, I decided that there would not have been any default at all. What happens if -st is used while -mt should have been used and the other way around? Linker erorrs? If not, isn't the second case much safer? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
