On Fri, Dec 03, 2010 at 03:54:49PM -0200, Fernando Lemos wrote: > Hi Roger, > > On Fri, Dec 3, 2010 at 3:41 PM, Roger Leigh <rleigh@codelibre.net> wrote: > [...] > > btag *does* use boost::system, even though you don't want to use it. > > Right now, with the g++4.5 and/or the gold linker, you aren't linking > > with a library you need. And I'm afraid that right at this point in > > time, it does need solving in btag. > > >From the compiler perspective, it does use boost::System. From the > developer perspective, it doesn't. Sure, I can patch the build system > to include -lboost_system, but what if Boost 1.4.3 depends on another > library? It's madness, this doesn't scale at all. Boost has *never* scaled. Correct support for UNIX-like systems has never been present. As someone who has used it in Debian over the last six years or so, we've gone through several changes of library names (-st or -mt suffix, or no suffix, with or without extra threading options or your program faults randomly). Linking has been unstable, and this is IMO just another aspect of the lack of integrated support for UNIX systems. Writing configure support to enable building on multiple Debian releases e.g. oldstable, stable, unstable, has been troublesome to say the least. Windows is even worse, but developers for that platform are masochistic by nature. They install multiple versions in separate directories, obviously not in standard locations because there are none, and hard code the paths in their sources, then ship the DLLs with their programs. Horrible. I think this way of working shows itself in how Boost does things, like -st/-mt suffixes where on Linux we would just build a single multithreaded library and be done with it (or support both in a single library like libc). > > Now arguably, boost should provide that information for use, but > > right now it *doesn't*, and it is the user's responsibility to do > > the donkey work. This information isn't specified in the library > > dependencies, so they can't be used as a substitute. > > Their reasoning I think is that the dependency is already encoded in > the DSOs, no need to make that information redundant. If they did > provide this info, I'd agree on following it to the letter and adding > that dependency information to the build system. It has worked this way in the past, and I totally agree that it's preferable from the developer's point of view. But, from a binary compatibility POV, indirect linkage is a lottery--it will work fine at initial link time, but you're subject to breakage at some unspecified future point when the depending library changes its dependencies. 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.
Attachment:
signature.asc
Description: Digital signature