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