Boost logo

Boost :

From: Steve M. Robbins (steve_at_[hidden])
Date: 2008-05-01 12:27:13

On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote:
> on Thu Mar 13 2008, "Steve M. Robbins" <> wrote:
> > 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.
> I'm not sure that's the end of the story. One reason we embed the
> compiler name in the library name is that version-specific workarounds
> often show up in header files. The result is that when compiled against
> gcc-4.2, client code will effectively see different header contents than
> the precompiled boost library that was built with gcc-4.1 did.

Interesting. I didn't know that. Debian's "unstable" distribution
has been using the same compiled Boost libraries with a mix of GCC 4.1
and 4.2 since December. GCC 4.3 is being added to the mix, too.

I should grep the boost headers for BOOST_WORKAROUND to see what
differences might arise.

> I think we'd need to work out a discipline of avoiding
> BOOST_WORKAROUND code in headers that distinguishes compiler minor
> versions. I'm not very confident that I've thought that issue
> through completely... is it that simple?

If possible, that would be nice from a library distributor's
point of view.

> > 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].
> This is just a change to bjam? Have you gotten any traction with that
> idea?

It turns out to be simpler than that. With a small tweak to boost's
Jamroot file, I'm now generating libraries without the toolset and
without the Boost version decorations. I will use this for the
upcoming Boost 1.35.0 Debian packages.

We had a long thread in Boost.Build about this idea [1]. I'm not sure
I convinced anyone to my point of view. :-) We'll proceed with
Debian-specific changes for the short term and see how it goes.


[1] Thread starts at
The shortest statement of Debian's position is
(And please ignore
 as I've changed my mind again)

Boost list run by bdawes at, gregod at, cpdaniel at, john at