On Thu, Jul 01, 2021 at 12:52:51PM -0500, Richard Shaw wrote: > On Thu, Jul 1, 2021 at 12:35 PM Kaleb Keithley <kkeithle@xxxxxxxxxx> wrote: > > <top post> > > Or, if I may be so bold— > > Convince the developers to use versioned symbols when they break the API/ > ABI. > > This is the 21st Century, and we have solutions for this. It's not rocket > surgery. > > </top post> > > That's actually not a problem most of the time. Some upstreams even > unnecessarily bump their soversion. But maintaining two (or > potentially more) versions of a library does create significant > extra work for the packager. One example is the Coin package, > currently Coin2/Coin3/Coin4 with all the alternatives gunk. 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 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org _______________________________________________ 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
