[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,
directly.

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
system.

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.


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


Reply to: