Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?

From: Steve M. Robbins (steve_at_[hidden])
Date: 2008-03-13 02:57:03

On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote:
> 
> on Sat Feb 23 2008, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:

    [...]

> > This produces pairs of library files such as
> >
> > 	bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
> > 	bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a
> >
> > (and similar pairs for shared libraries and all other variants).
> >
> > The key item to note is that the two files have the same name.  The
> > python version, unlike the GCC version, is not embedded in the library
> > name.  So these files cannot both be installed into /usr/lib.
> 
> I don't know how such name gristing is generated in Boost.Build, but IMO
> we should change the naming to account for the Python version.

Perhaps.  For the moment, I can get the desired effect using
--buildid.

> > The question, then, is how to distinguish them once installed?  
> > Should we:
> >
> >
> > 1. Rename the resulting libraries to decorate them with the python
> > version in addition to the gcc version?  This could generate
> >
> > 	libboost_python-py24-gcc42-1_34_1.a
> > 	libboost_python-py25-gcc42-1_34_1.a
> 
> I'm not an expert in this area, but it's been my understanding that
> simply renaming library files doesn't work for some reason.

Partly true.  I believe you can rename the static libs (.a files) at
will.  The problem lies in the shared libs.  Subsequent to writing the
above, I discovered that the two shared libraries (.so.*) have exactly
the same SONAME, so renaming doesn't work for them.

> > 2. Similar to above, but use bjam's --buildid option?  This has the
> > drawback that the build ID shows up differently than the GCC version
> > decoration, e.g.
> >
> > 	libboost_python-gcc42-1_34_1-py24.a
> > 	libboost_python-gcc42-1_34_1-py25.a
> 
> Sounds more likely to work, even though it's ugly.

Yes, this works because the --buildid is incorporated into the
SONAMEs, thus distinguishing them.  Using --buildid is therefore the
*only* solution short of hacking the soname generation myself.

> > I'd appreciate your thoughts.  Have I overlooked a better solution?
> > What are the other packagers of Boost.Python doing?  
> 
> Unfortunately, we don't tend to get a lot of interaction with packagers
> around here, so we don't tend to know what they're doing.  I think Boost
> raises more packaging issues than most other libraries, so it would be
> good to have more involvement from y'all.

Actually, the only thing about Boost that causes grief to packagers is
that the toolset name (e.g. "gcc42") is embedded in the library
filename.  I just wrote a response on Boost.Build outlining this in
some detail [1].  Embedding the compiler version requires Debian to
rebuild all the boost packages each time a compiler change is made.
This is unnecessary when the compiler ABI is maintained (e.g 4.1 ->
4.2) and also unnecessary when the ABI is broken, as Debian has
another mechanism to handle that.  Note that rebuilding the boost
packages has a huge ripple effect, so it is more than simply
"unnecessary", it is a very large headache.

The fact that Boost embeds the Boost version in the library name is
cause for grief to client software authors.  But this is unavoidable
as long as Boost doesn't take care to maintain ABI across versions.
Fortunately, there is a simple solution to this, which I touch on in
my post [1].

Regards,
-Steve

[1] http://lists.boost.org/boost-build/2008/03/18565.php