linux build and version symlinks question
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/47ef674f752ad2cfeb581665cbea18ee6fa... 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
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.
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.
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. Stefan -- ...ich hab' noch einen Koffer in Berlin...
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/f1058cd9564aefc607a29ca04812d5... 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
On 2020-06-15 17:09, Aleksei Nikiforov via Boost wrote:
Not sure what happens with them in Debian, but those symlinks seem to be not packaged as well.
Debian/Ubuntu packages do have symlinks - in dev packages. Binary packages only contain libraries with ABI version tags in their names. https://packages.debian.org/buster/amd64/libboost-filesystem1.67-dev/filelis... https://packages.debian.org/buster/amd64/libboost-filesystem1.67.0/filelist In general, you do want the untagged library names available only in dev packages to enable linking with the library. In binary packages you want tagged library names to allow installing multiple ABI-incompatible versions of the library on target systems. Since Boost does not maintain ABI compatibility, this means Boost libraries include the full Boost version as the ABI tag.
15.06.2020 17:28, Andrey Semashev via Boost пишет:
On 2020-06-15 17:09, Aleksei Nikiforov via Boost wrote:
Not sure what happens with them in Debian, but those symlinks seem to be not packaged as well.
Debian/Ubuntu packages do have symlinks - in dev packages. Binary packages only contain libraries with ABI version tags in their names.
https://packages.debian.org/buster/amd64/libboost-filesystem1.67-dev/filelis...
https://packages.debian.org/buster/amd64/libboost-filesystem1.67.0/filelist
In general, you do want the untagged library names available only in dev packages to enable linking with the library. In binary packages you want tagged library names to allow installing multiple ABI-incompatible versions of the library on target systems. Since Boost does not maintain ABI compatibility, this means Boost libraries include the full Boost version as the ABI tag.
There are no libboost_filesystem.so.1.67 and libboost_filesystem.so.1 symlinks in boost 1.67.0. Let's take a look at boost 1.71.0. In Debian only libboost_filesystem.so is packaged into dev package, and libboost_filesystem.so.1.71.0 is packaged into library package. libboost_filesystem.so.1.71 and libboost_filesystem.so.1 are missing while they should be present after boost build: https://packages.debian.org/sid/amd64/libboost-filesystem1.71-dev/filelist https://packages.debian.org/sid/amd64/libboost-filesystem1.71.0/filelist I'm not much familiar with Debian's package building system, but I couldn't find any mentions of disabling or removing two missing symlinks, thus my guess is that those two symlinks are just ignored and not packaged. Kind regards, Aleksei Nikiforov
On 2020-06-15 17:43, Aleksei Nikiforov via Boost wrote:
15.06.2020 17:28, Andrey Semashev via Boost пишет:
On 2020-06-15 17:09, Aleksei Nikiforov via Boost wrote:
Not sure what happens with them in Debian, but those symlinks seem to be not packaged as well.
Debian/Ubuntu packages do have symlinks - in dev packages. Binary packages only contain libraries with ABI version tags in their names.
https://packages.debian.org/buster/amd64/libboost-filesystem1.67-dev/filelis...
https://packages.debian.org/buster/amd64/libboost-filesystem1.67.0/filelist
In general, you do want the untagged library names available only in dev packages to enable linking with the library. In binary packages you want tagged library names to allow installing multiple ABI-incompatible versions of the library on target systems. Since Boost does not maintain ABI compatibility, this means Boost libraries include the full Boost version as the ABI tag.
There are no libboost_filesystem.so.1.67 and libboost_filesystem.so.1 symlinks in boost 1.67.0.
Why would they be needed? Such multi-layered symlinks are created in cases when there are different guarantees offered by different library names or backward compatibility reasons (e.g. the library was renamed or changed its tagging scheme at some point). This is not the case with Boost, so there's no point in creating or packaging them.
Let's take a look at boost 1.71.0. In Debian only libboost_filesystem.so is packaged into dev package, and libboost_filesystem.so.1.71.0 is packaged into library package. libboost_filesystem.so.1.71 and libboost_filesystem.so.1 are missing while they should be present after boost build:
https://packages.debian.org/sid/amd64/libboost-filesystem1.71-dev/filelist https://packages.debian.org/sid/amd64/libboost-filesystem1.71.0/filelist
What makes you think libboost_filesystem.so.1.71 and libboost_filesystem.so.1 should be present?
Andrey Semashev wrote:
There are no libboost_filesystem.so.1.67 and libboost_filesystem.so.1 symlinks in boost 1.67.0.
Why would they be needed?
They wouldn't be, that's the whole point of the thread, that we're currently generating them, and we used not to generate them, and that we _probably_ should revert to not generating them.
On 2020-06-15 19:09, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
There are no libboost_filesystem.so.1.67 and libboost_filesystem.so.1 > symlinks in boost 1.67.0.
Why would they be needed?
They wouldn't be, that's the whole point of the thread, that we're currently generating them, and we used not to generate them, and that we _probably_ should revert to not generating them.
Oh, ok. I must have misunderstood then.
Aleksei Nikiforov wrote:
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/47ef674f752ad2cfeb581665cbea18ee6fa...
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?
It was an unintentional change.
Aleksei Nikiforov wrote:
Besides just removing those symlinks after installation, what's the proper way for disabling creating these additional symlinks when building/installing boost using b2?
I tried `b2 install install-no-version-symlinks=on`, but it had no effect. So I guess the answer is "none". I suppose the right thing to do is to reverse the change and reinstate the original behavior to not install these symlinks on `b2 install`. I'm not quite sure about `b2 stage`, but it should probably be consistent with `b2 install`, because many packaging scripts use `stage` instead of `install` for some reason.
participants (4)
-
Aleksei Nikiforov -
Andrey Semashev -
Peter Dimov -
Stefan Seefeld