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