Re: How to (better) deal with library major API changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 1, 2021 at 1:52 PM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:

I don't think that's what Kaleb was suggesting.  Coin2/3/4 packages
contain different SONAMEs:

# dnf repoquery -l Coin4 | grep /usr/lib64
/usr/lib64/libCoin.so.4.0.0
/usr/lib64/libCoin.so.80
# dnf repoquery -l Coin3 | grep /usr/lib64
/usr/lib64/libCoin.so.60
/usr/lib64/libCoin.so.60.1.3
# dnf repoquery -l Coin2 | grep /usr/lib64
/usr/lib64/libCoin.so.40
/usr/lib64/libCoin.so.40.5.0

Now I don't know if it would specifically work for Coin, but for many
C/C++ libraries you can use a single SONAME forever, and versioned
symbols for each symbol that has to change incompatibly.  Old binaries
will continue to use the old symbol transparently.  New binaries will
use the new symbol.  Both will be linked to the same SONAME.

glibc is the most famous/notorious user of this mechanism, but many
other libraries use it too.  Uli's documentation is a good place to
start:

https://akkadia.org/drepper/dsohowto.pdf

as well as:

https://gcc.gnu.org/wiki/SymbolVersioning

Is that something that can be easily implemented at the packager level?

Also, in the case of OpenEXR upstream (ASWF) has reorganized the libraries over the last couple of releases[1], merging some and splitting out others creating a real mess. In fact, one of the other ASWF projects, OpenVDB isn't even compatible with OpenEXR 3 and won't be until the next major release. 

So is my only real option to create a compat package and migrate all the projects that can't use OpenEXR 3 to it? 

For posterity here's my working COPR with the fairly long list of dependencies:

https://copr.fedorainfracloud.org/coprs/hobbes1069/openexr/builds/

Thanks,
Richard 

[1] https://github.com/AcademySoftwareFoundation/Imath/blob/master/docs/PortingGuide2-3.md
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux