Domenico Andreoli <[EMAIL PROTECTED]> 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.
pgpiqP3kIZ1OE.pgp
Description: PGP signature
