Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] RFC sonames initial implementation
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-10-29 18:15:26

Brad King wrote:
> If there is no interface version, there is no need for the soname to be
> different from the real binary name. IOW, we could just set VERSION=1.2
> and no SOVERSION, and CMake will produce
> -> # link to help static linker -lfoo flags
> # real binary, soname =
> Whenever a binary links to foo, it will copy the soname "".
> The dynamic loader will search for that name at runtime and find the
> real file.
>> should we hash out the above SOVERSION-only suggestion further?
> That is for Boosters to decide, so I won't

Thanks for the explanation, we'll go w/o interface version only as you

>> 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?
> CMake's implementation to pass those flags does this:
> // Add OSX version flags, if any.
> if(this->Target->GetType() == cmTarget::SHARED_LIBRARY ||
> this->Target->GetType() == cmTarget::MODULE_LIBRARY)
> so it should work for SHARED and MODULE libraries equally.
> Perhaps the boost CMake code is not setting SOVERSION.

Hmm. It isn't setting it on purpose... If I set either VERSION or
SOVERSION on a module on the mac, I get:

Linking CXX shared module ../../../lib/
cd /Users/troy/cmake/build/libs/mpi/src && /Users/troy/bin/cmake -E
cmake_link_script CMakeFiles/mpi-mt-shared.dir/link.txt --verbose=1
/usr/bin/c++ -bundle -headerpad_max_install_names -Wl,-u,_munmap
-compatibility_version 1.41.0 -o ../../../lib/
CMakeFiles/mpi-mt-shared.dir/python/py_timer.cpp.o -framework Python
../../../lib/libboost_python-mt.1.41.0.dylib -framework Python
i686-apple-darwin9-g++-4.0.1: -compatibility_version only allowed with


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