Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix
From: Denis Arnaud (denis.arnaud_boost_at_[hidden])
Date: 2009-10-29 05:00:38

2009/10/28 troy d. straszheim <troy_at_[hidden]>

> And the soname would read something like:
>> $ readelf -a /usr/lib/ | grep -i soname
>> 0x0000000e (SONAME) Library soname:
>> []
>> (that example is taken from Fedora 11, with Boost 1.37.0; the soname
>> version is fixed within the RPM specification file).
> % readelf -a build/lib/ | grep SONAME
> 0x000000000000000e (SONAME) Library soname:
> []
> OK?

As the discussion<>,
which took place on the Debian list, mentioned, having the sonames following
the Boost versions may be a little bit too harsh (imposing developers who
embed Boost libraries to re-link their own binaries four times a year). On
Fedora, the soname seems to follow its own versionning logic (which I have
to investigate with the Boost package owner, name Benjamin Koznik), since
for example the soname for Boost 1.37 was 4, and the soname for Boost 1.39
is 5.

Personally, I'd rather have, as you suggest, a soname versionning system
following Boost's one. Indeed, Fedora is released twice a year, and the
Boost libraries are not upgraded during the lifetime of a given Fedora
version (and it seems to be same with RedHat, though on a much longer
life-cycle). So, I do not see why it should harm the stability of a Linux
distribution to get a simple one-to-one mapping between Boost versionning
and soname versionning.

Nevertheless, I still believe it is better to get some soname, which could
be a configuration parameter of the CMake building system (including for the
soname version), than no soname at all!


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