Boost logo

Boost-Build :

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-04-14 01:52:31

Steve M. Robbins wrote:
> In this manner, the SONAME ""
> is embedded in the binary and is used at runtime
> regardless of what points to or whether it even exists.
> Now you see that "-lfoo" doesn't have any version info. Generally we
> assume that client code doesn't care whether it links to version
> 1.3.32 or to version 1.3.31.
> So long as a library with the SONAME embedded in your application
> binary still exists, the application works. As background, you should
> understand that Debian places each shared library in its own package,
> with the library SONAME embedded in the package name.
> There are two cases.
> First, if the upgrade is an ABI change (change of SONAME), then the
> new library lives in a package that can be co-installed with the old
> package. The old library package is therefore unaffected by the
> upgrade and the application continues to work.
> The SONAME is the ABI identifier.
> Most libraries use a
> Major.Minor.Revision numbering and guarantee ABI compatibility at the
> Major version level (some at the Minor version level). The library is
> then named something like with a SONAME of
> "". Remembering the algorithm of the run time loader, we
> then also need a symlink --> And for
> the link time file, we have a symlink -->
> I'm not sure. While many libraries guarantee ABI compatibility across
> micro versions, it's not universally the case.
> This is a small issue and vendors like Debian can deal with frequent
> SONAME changes. I'd rather have that than deal with bugs caused by
> accidental ABI changes. C++ is notoriously hard to audit for ABI
> changes.
> The larger issues are that Boost embeds the boost version and compiler
> name into the library name. I'd really prefer to address these first.

Given all that, and these:

a) The Boost ABI is *never* guaranteed stable across *any* two versions.
And is almost always certain to be different based not just on version
but compiler and compilation options. (For the simple reason that much
code in Boost is conditionally selected based on all those factors)

b) That, as far as I understand, the lib*.so.X.Y.Z arrangement is to
allow for selection among possibly compatible ABIs.

c) That because of (a) we want to prevent the application of the
heuristics that support (b).

d) That for user safety, as relating to running programs compiled with
the same Boost version but different compiler versions, we want to
prevent the possibility of cross-compiler code being loaded in the same
image. Even in the face of compiler vendor assurances that the produced
ABI is the same.

d) That we want to facilitate ease of use by having the unversioned names.

Would this plan work for packagers:

1) We drop the --layout=system option.

2) We change the SONAMEs to match the base versioned library names, with
the fixed tail version number as some OSs require some version number.
(As I mention in another post)

3) We add a --package-version=X.Y (the default being 0.0 always). Which
packagers can use as they see fit.

4) We add a --install-as-default option that will create the unversioned
(neither Boost nor compiler) links (sym or hard based on OS support) for
the libraries *and* the headers directory. The option would include a
prominent note in the documentation that this will override the existing


-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ (msn) - grafik/
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

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