Denis Arnaud wrote: > 2009/10/28 troy d. straszheim <t...@resophonic.com> > >> Would it be possible to have the option, with CMake build, to use a >>> more conventional soname, so that Linux distribution packagers >>> (Debianers and RPM-based packagers such as me, for instance) be >>> happy (i.e., have less extra code to write)? >>> >>> So, like this (?): >> >> % ls -l build/lib >> total 1352 >> libboost_iostreams-mt-d.a >> libboost_iostreams-mt-d.so -> libboost_iostreams-mt-d.so.1.41* >> libboost_iostreams-mt-d.so.1.41 -> libboost_iostreams-mt-d.so.1.41.0*
Whether this link should be present depends on whether soname has "1.41" or "1.41.0" at the end. If it has "1.41.0", to reflect the lack of any BIC between any versions of Boost, then 1.41->1.41.0 symlink is not really necessary. And whether point releases are required to have any binary compatibility or not is a tricky question, especially given that "upstream" does not want any point releases at all. >> libboost_iostreams-mt-d.so.1.41.0* >> libboost_iostreams-mt.a >> libboost_iostreams-mt.so -> libboost_iostreams-mt.so.1.41* >> libboost_iostreams-mt.so.1.41 -> libboost_iostreams-mt.so.1.41.0* >> libboost_iostreams-mt.so.1.41.0* >> > > Yes, exactly :) > > 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). This might be obvious, but such a soname would be wrong if the above naming of libraries is used, since there would be no libboost_date_time-mt.so.4. - Volodya _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
