On Fri, Dec 3, 2010 at 10:38 PM, Roger Leigh <rle...@codelibre.net> wrote: >> 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.
Why is this a problem? I don't see how a lot of the interfaces Boost provides could be done with binary compatibility. >> > 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? The header knows what version it is, so it can use that to link to the correct lib. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim4ccoqwe5chccf2w56m0mgyxyskfqtuh5j-...@mail.gmail.com
