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 <email@example.com> wrote: > > On Fri, Dec 3, 2010 at 6:41 PM, Roger Leigh <firstname.lastname@example.org> 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.
Description: Digital signature