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
>> 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 list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk