Boost logo

Boost Interest :

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

Brad King wrote:
> Denis Arnaud wrote:
>> 2009/10/28 Vladimir Prus <vladimir_at_[hidden]
>> <mailto:vladimir_at_[hidden]>>
>> This might be obvious, but such a soname would be wrong if the above
>> naming
>> of libraries is used, since there would be no
>> - 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



Is there some standard buildtime toggle for this, or is

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

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?


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