Re: [Boost-build] Boost library naming scheme

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

Steve M. Robbins wrote:
[...]
> In this manner, the SONAME "foo.so.1.3.32"
> is embedded in the binary and foo.so.1.3.32 is used at runtime
> regardless of what foo.so 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 libfoo.so.1.35.0 with a SONAME of
> "libfoo.so.1".  Remembering the algorithm of the run time loader, we
> then also need a symlink libfoo.so.1 --> libfoo.so.1.35.0.  And for
> the link time file, we have a symlink libfoo.so --> libfoo.so.1.35.0.
[...]
> 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 
default.

??

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail