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

Re: List of FTBFS in Ubuntu

On Fri, Dec 03, 2010 at 02:52:12PM -0200, Fernando Lemos wrote:
> On Fri, Dec 3, 2010 at 12:08 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> > While I do find this a rather annoying violation of encapsulation,
> > you will find (e.g. with "nm -C -D") your binary will have
> > boost::system symbols in it which are only satisfied indirectly
> > via libboost_filesystem and which would result in breakage if
> > libboost_filesystem drops that dependency and you don't explicitly
> > link against it.  Ideally, the headers should be fixed.
> The thing is, libboost_filesystem is not supposed to drop their
> dependency on libboost_system unless its headers no longer refer to
> boost::system. The requirement of linking to boost::system is an
> implementation detail of boost::filesystem that package maintainers
> should *not* have to worry about.

We shouldn't have to worry about it, it should be an implementation
detail.  Unfortunately, it isn't, and we do need to worry about it.

The fact that libboost_filesystem *shared object* depends upon the
libboost_system shared object, has no bearing upon addition
dependencies brought in by the *headers*.

> Boost works on the assumption that the linker will consider the
> dependencies of the DSOs. You can say it's a Boost bug, you can say
> it's a binutils-gold bug (for changing a behavior that people relied
> on for the sake of performance), or you can say it's a
> CMake/pkg-config bug (for not listing the right dependencies for
> boost::filesystem), but it's in no way a bug in btag or any other
> package that links against libboost::filesystem, libboost::asio and
> countless other C++ libraries in the same situation.

I don't agree with these conclusions.  I'd like to, because I've
got exactly the same issues with schroot, but after spending some
time considering it, it's not correct.

From #602959:
"btag does not use boost::system at all, and therefore it would not
make any sense to think this is a problem btag must solve"

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.

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.

Why?  If you link indirectly today, and later on boost_filesystem
drops its boost_system dependency, your code will break because
those inlined functions are in *your* code, not the filesystem
library.  You'll get a link failure.  By linking explictly, you're
protected against future failure.

Just for the record, C++ templates don't require inlining; you can
specifically instantiate and export particular instances to avoid
this.  Full support for exported templates in g++ would also be
useful, but we've been waiting over a decade for that and it's due to
be removed from the standard.

> So I think it would be *really* nasty if ever developer had to work
> around a bug somewhere because something else is broken.

It's arguable whether it's a bug or not.  Maybe this is what was
specifically intended?  We do need a scalable approach to dealing
with this, and I'd suggest pkg-config should be the route to take.
But until such time we have a solution like that in place, the
onus is on the library users to link correctly, and it is going
to be a major problem.


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