Brad King wrote:
Denis Arnaud wrote:
2009/10/28 Vladimir Prus <vladi...@codesourcery.com
<mailto:vladi...@codesourcery.com>>
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
I've just checked what Debianers do. Currently, they set the soname to
match the full library name
[snip]
From some documentation, I understand that the SOVERSION attribute
should be changed for each library, but I do not see where it should be
configured.
Boost has no separate interface and implementation versions, so it may be
best to just set the VERSION property on all libraries and no SOVERSION
(or vice-versa...each defaults to the other). Then CMake will only create
libboost<component>.so -> libboost<component>.so.1.41.0
libboost<component>.so.1.41.0
and the SONAME field will be "libboost<component>.so.1.41.0".
It looks like Boost's CMake framework has comments about SOVERSION in
tools/build/CMake/BoostCore.cmake
Docs:
http://sodium.resophonic.com/boost-cmake/current-docs/build_configuration.html#build-soversioned
Questions:
Is there some standard buildtime toggle for this, or is
BUILD_SOVERSIONED okay?
The option is avaiable on UNIX only.
The implemenation sets VERSION to e.g. 1.41 and SOVERSION to 1.41.0,
this gets me the symlinks that look most familar to me, no better
reason. Ok, or should we hash out the above SOVERSION-only suggestion
further?
The implementation does *not* set soversion on libraries of type MODULE,
as the mac linker complains about -compatibility_version when making a
bundle. Am I missing anything?
-t
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
