linux build and version symlinks question

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

linux build and version symlinks question

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list

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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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/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?

It was an unintentional change.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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/filelist
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
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/filelist
>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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/filelist
>>
>> 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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> 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.

See https://github.com/boostorg/boost_install/issues/43 and
https://github.com/boostorg/boost_install/commit/ea28ed441fb04f2c5839e99e37f4c173fcfd48ec.
If you see something wrong with these changes please let me know.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: linux build and version symlinks question

Boost - Dev mailing list
15.06.2020 21:26, Peter Dimov via Boost пишет:

>> 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.
>
> See https://github.com/boostorg/boost_install/issues/43 and
> https://github.com/boostorg/boost_install/commit/ea28ed441fb04f2c5839e99e37f4c173fcfd48ec.
> If you see something wrong with these changes please let me know.
>

It works as expected. Thank you.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost