2009/10/28 troy d. straszheim <t...@resophonic.com> > And the soname would read something like: >> $ readelf -a /usr/lib/libboost_date_time-mt.so | grep -i soname >> 0x0000000e (SONAME) Library soname: >> [libboost_date_time-mt.so.4] >> (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/libboost_iostreams-mt.so | grep SONAME > 0x000000000000000e (SONAME) Library soname: > [libboost_iostreams-mt.so.1.41] > > OK?
As the discussion<http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2008-November/001611.html>, 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! Denis
_______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
