Boost logo

Boost :

From: Aleksei Nikiforov (darktemplar_at_[hidden])
Date: 2020-06-15 14:09:23


15.06.2020 16:46, Stefan Seefeld via Boost пишет:
>
> On 2020-06-15 8:46 a.m., Aleksei Nikiforov via Boost wrote:
>> Hi.
>>
>> I've noticed that some versions ago boost started creating additional
>> symlinks when built for linux. In addition to boost_${library}.so ->
>> boost_${library}.so.A.B.C symlink, two more symlinks are created:
>> boost_${library}.so.A -> boost_${library}.so.A.B.C and
>> boost_${library}.so.A.B -> boost_${library}.so.A.B.C.
>
> This is a Linux convention to support multiple co-existing versions,
> assuming that the rules for semantic versioning are followed.
>
> Note however that Boost doesn't follow semantic versioning. Its normal
> builds add the version numbers to the library names, so conceptually two
> versions of the same library are actually considered two distinct
> libraries by the linker.
>

Thanks, but my question is not about what it is. It's about why it was
changed in boost to this state from previous one. I couldn't find any
documentation on that change or any explanation in linked commit.

> That would be an issue to be reported to downstream package maintainers
> (in Fedora, Debian, or wherever you encounter the problem), as that is
> where Boost libraries are built without the version numbers in their
> name. This is presumably because the Linux distros' package managers
> assure that multiple versions will never be installed side-by-side,
> precisely to prevent this kind of issue.
>

And another my question is about proper way of building boost with those
symlinks disabled. For example, in Fedora, those new symlinks are just
manually removed:

https://src.fedoraproject.org/rpms/boost/blob/f1058cd9564aefc607a29ca04812d5cca280a0ca/f/boost.spec#_898

Not sure what happens with them in Debian, but those symlinks seem to be
not packaged as well.

Is there any options to disable these symlinks that can be passed to b2?

Kind regards,
Aleksei Nikiforov


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk