Boost logo

Boost :

From: Aleksei Nikiforov (darktemplar_at_[hidden])
Date: 2020-06-15 12:46:54


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.

Additional symlinks started appearing approximately around version 1.70.0.

For example, boost 1.67.0 has library libboost_filesystem.so.1.67.0 and
a symlink libboost_filesystem.so.
Boost 1.73.0 has library libboost_filesystem.so.1.73.0 and 3 symlinks:
libboost_filesystem.so, libboost_filesystem.so.1 and
libboost_filesystem.so.1.73.

My guess is that this change was introduced in following commit by
removing install-no-version-symlinks feature for all libraries:

https://github.com/boostorg/boost/commit/47ef674f752ad2cfeb581665cbea18ee6faecd2e#diff-09cc8a80ee9a61cf35f9c4498eefd67aL344

I couldn't find any mention of such change in changelog or any
explanation or description of intention of this change. Did I miss it?
Was it an unintentional change?

In binary linux distributions, *.so files and header files are usually
packed into devel packages, while *.so.* are packed into library
packages. In case of boost and those symlinks it can lead to an issue.
For example, during upgrade from boost 1.72.0 to boost 1.73.0, while
both boost 1.72.0 libraries and 1.73.0 libraries are needed temporarily,
boost_${library}.so.1 symlinks from both packages may conflict. These
symlinks with same names point to different libraries. It's not an issue
for devel packages and *.so symlinks with same names since you don't
need two devel packages being installed at same time during upgrade.

Besides just removing those symlinks after installation, what's the
proper way for disabling creating these additional symlinks when
building/installing boost using 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