[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:58:13PM -0200, Fernando Lemos wrote:
> Hi, Olaf
> On Fri, Dec 3, 2010 at 3:49 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> > On Fri, Dec 3, 2010 at 6:41 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> >> 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.
> >
> > If the boost_system code is removed from the boost_filesystem headers
> > and the dependency is dropped, why would you get a link failure?
> What Roger is referring to is the situation where boost::filesystem's
> DSO no longer depends boost_system, but the header files still use
> boost::system in inlined methods. That, however, is very unlikely (and
> probably would be treated as a Boost bug), as it would cause a lot of
> FTBFS issues, even with --add-needed.

No, that's not what I mean.

When you link your code with -lboost_filesystem, you get this:

  program → NEEDS libboost_filesystem
  libboost_filesystem → NEEDS libboost_system

When you link your code with -lboost_filesystem -lboost_system,
you get this:

  program → NEEDS libboost_filesystem
  program → NEEDS libboost_system
  libboost_filesystem → NEEDS libboost_system

Now, remember that due to the inlined header functions, "program"
uses symbols from both libboost_filesystem AND libboost_system.
In the first case, these are satisfied indirectly; in the second,

Now, consider what happens if libboost_filesystem drops its
libboost_system dependency.  NOTE: we're not considering rebuilding
from source here, we're concerned with BINARY compatibility, i.e.
our compiled program working with future boost packages on the

In the first instance, the dependencies would become:

  program → NEEDS libboost_filesystem

Since program needs symbols from libboost_system and the indirect
dependency is no longer satisfied, "program" will no longer run.
If this was packaged software, dpkg-shlibdeps wouldn't have
picked up on this, and even though the package dependencies are
satisfied, it will still fail to run.

Now, in the second case, we get:

  program → NEEDS libboost_filesystem
  program → NEEDS libboost_system

The compiled code still continues to run, due to the direct linkage.
If packaged, dpkg-shlibdeps will compute the correct package
dependencies and everything should continue to work.

Hope this explains where I'm coming from a bit better.


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