From: Steve M. Robbins (steve_at_[hidden])
Date: 2008-04-15 01:05:43
On Mon, Apr 14, 2008 at 12:52:31AM -0500, Rene Rivera wrote:
> 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.
The SONAME is the ABI identifier. Because of (a), Boost (correctly)
uses SONAME "libfoo.so.X.Y.Z" for library libfoo.so.X.Y.Z and no two
versions of "foo" will ever be identified as compatible.
So either I'm missing your point, or you are misunderstanding ABI
labelling on unix. Maybe both :-)
> c) That because of (a) we want to prevent the application of the
> heuristics that support (b).
I don't understand what you want to say. But it suggests that,
indeed, there is a misunderstanding of ABI labelling.
> 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.
This is a laudable goal. I don't want to dissuade you from keeping this
the default. I just want a way to disable it.
> d) That we want to facilitate ease of use by having the unversioned names.
An important clarification is that we want unversioned LINK names only.
The actual SONAMEs **must** be versioned.
> 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)
The current SVN head already produces shared objects whose SONAME
matches the library name. For example, here's what I see after bjam;
(1) The library libboost_date_time-gcc42-mt-1_35.so.1.35.0 with
(2) A symlink to (1) named libboost_date_time-gcc42-mt-1_35.so; and
(3) A hard link (very unusual!) to (1) named
So I'm not sure what you are proposing; I need an example.
> 3) We add a --package-version=X.Y (the default being 0.0 always). Which
> packagers can use as they see fit.
What is the proposed behaviour of --package-version=X.Y?
> 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
I don't think this helps me. What I need is to have the SONAME
(and therefore the library file name) devoid of compiler version.
I also need a LINK library name devoid of Boost version; I think
your proposal provides that. Again, however, I need an example
to be sure.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk