Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2008-03-12 21:11:25

on Sat Feb 23 2008, "Steve M. Robbins" <> wrote:

> Hi,
> I'm part of the Debian Boost packaging team, seeking some guidance on
> how to build and install Boost.Python so that it is usable with all
> Python versions shipped in Debian. Debian currently ships Python 2.4
> and 2.5.
> When reading the following, keep in mind that Boost.Python is not a
> Python extension but, rather, a library that eases writing an
> extension in C++. So it is necessary that the compiled libraries be
> visible to be linked with user-written C++ code.
> One idea is to use a user-config.jam file containing
> using python : 2.4 : /usr ;
> using python : 2.5 : /usr ;
> Then run jam twice
> bjam variant= ...
> bjam variant= ... python python=2.5

Well, you can run it once:

      bjam python=2.4,2.5


> 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. This is
really a question for the Boost.Build list, I think.

> 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.

> 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.

> 3. Put the libraries in different subdirectories, e.g.
> /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a
> /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a

You could do that, and then provide symlinks with the python version
grist in /usr/lib
> 4. Put the default version directly in /usr/lib and the others
> in subdirectories, e.g.
> /usr/lib/libboost_python-gcc42-1_34_1.a
> /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a
> The drawback to all these approaches is that client code has to be
> adjusted to build on Debian. Linking against Boost (for non-bjam
> projects) is already hard enough with the decorated library names that
> I fear making the situation worse.


> The attraction of #4 is that at least the variants for the default
> python version are found in a natural manner. This has some appeal to
> me, personally, but I worry that it is too easy to build an extension
> to python 2.5 and link in the wrong Boost.Python library. In
> contrast, the other options have the advantage that it forces the user
> to declare which version of Python is being used.
> 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.

> In principle, it would be nice to have the Boost libraries named the
> same across distributions.

No doubt!

Dave Abrahams
Boost Consulting

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