On Fri, Dec 03, 2010 at 10:23:39PM +0100, Olaf van der Spek wrote: > On Fri, Dec 3, 2010 at 10:09 PM, Roger Leigh <email@example.com> wrote: > > 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. > > Wouldn't this only happen on a major version change of the Boost package? > Thus requiring a recompile? This is hopefully what would happen. But there's no guarantee that this would be the case, and that's really down to whatever policy that the Boost developers have in place for API and ABI compatibility. We are only concerned with symbols in the compiled binaries, and if they are correctly linked so that all the symbols in the program are directly satisfied by their first-order dependencies. The encoding of Boost release numbers into their SONAME versioning is also part of the problem, since a recompile is unilaterally required with each major release, meaning there is zero effective binary compatibility between releases even if there are no changes. > > Hope this explains where I'm coming from a bit better. > > It does, a bit. > > BTW, got my mail about auto linking? I saw it, yes. I'm not sure how MSVC implements auto-linking, but I would be concerned about the determinism of such behaviour, especially when a given symbol could be satisfied by a number of different libraries. For Boost, a given symbol might be satisfied by a number of different library versions which could be installed concurrently; how would you know which was the correct one? 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