Boost logo

Boost-Build :

From: Steve M. Robbins (steve_at_[hidden])
Date: 2008-04-13 12:31:33

On Sun, Apr 13, 2008 at 11:04:35AM -0500, Rene Rivera wrote:
> Steve M. Robbins wrote:
> > From Debian's perspective, the name changes we'd like to see are:
> >
> > 1. Remove the compiler name.
> > 2. Remove the Boost version name.
> >
> > I'm going to do #1 for Debian's 1.35.0 packages in any case, but
> > having explicit upstream support for this is way better.
> I somehow always end up pointing this out... The compiler is put into
> the library name because using different compiler+stdc++ can cause ABI
> changes.

Yes it can, but often it doesn't. I'm told, for example, that
gcc 4.1 and gcc 4.2 are ABI compatible.

> So I have a simple question about the Debian packaging; What
> happens when the compiler version changes in the system but the library
> versions do not? Do you recompile all the packages to the new version?

Yes. When a compiler or standard library forces an ABI change, all
affected packages (libraries and applications) are rebuilt. This is
fairly painful for a distribution the size of Debian, but manageable.
It's mostly transparent to users, except that user code may need to
be recompiled.

> Are users forced to recompile all their code?

Effectively, yes.

When Debian rebuilds a library due to an externally-forced ABI change, we
produce a different package but since both the old and new packages install
the same library file they must conflict. In some cases, you can simply
refuse to install the new library package and continue using your old code.
However, for a library (like Boost) that is used by other packages, you'll
quickly be forced to install the new version and rebuild your local code.

> Recently I've been thinking that just dropping the association between
> the Boost version number and the SO version number is best. Since the
> version number is encoded in the library name itself anyway. For a frame
> of reference our current scheme follows
> <>:
> And dropping the SO version, and replacing it with a fixed release number:

With respect, that's backwards. The conventional scheme, as I
outlined, is to put the library version in the SONAME but not in the
"link name". That is, (for a single-threaded non-debug variant) the
library file name (and SONAME) is:

while for the linker there is the symbolic link -->

so that you can use "-lboost_qwerty" not caring about what version is

This is established convention in linux, so I don't understand why
you'd want to do anything differently.


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at