[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: List of FTBFS in Ubuntu

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


  .''`.  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

Reply to: