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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
