On 12/11/22 01:44, Richard Biener wrote:
On Sat, 10 Dec 2022, Lee Duncan wrote:
Hi Everyone:
Thank you for all the replies.
I'm not really an expert at libraries, so I've learned a bunch.
tl;dr -- my problem comes from building with meson and how it sets the SONAME
DETAILS: ======== When this library first appeared from upstream a few yeas ago, I had to package it. I at first named my package "libopeniscsiusr", but the build service complained until I named it "libopeniscsiusr0_1_0". I didn't understand (or care) why, at the time. [It turns out the SONAME was being set to "libopeniscsiusr.so.0.2.0"!]
More recently, when version 0.2.0 of the library came out, I didn't want to change anything in my SPEC file, but OBS made me name the package "libopeniscsiusr0_2_0", again because of the SONAME, though I didn't realize it at the time.
This package used to be build by Make, and the build line *specifically* set the SONAME! Here's basically what it did:
libopeniscsiusr.so.0.2.0: $(CC) $(CFLAGS) -shared -Wl,-soname=$@ -o $@ $(OBJS) $(LDFLAGS) $(LIBADD) ... (create symlinks)
Now I know the SONAME _should_ have been "libopeniscsiusr.so.0".
Recently, I changed this package to build using meson. In meson, I just tell it my library name and version, and it creates the SONAME:
libiscsi_usr = shared_library('openiscsiusr', libiscsi_usr_srcs, include_directories: [libiscsi_usr_private_includes, libiscsi_usr_public_includes], dependencies: kmod_dep, version: '0.2.0', c_args: genl_cargs, install: true)
Since meson created the shared libraries of the right name (and with the correct symlinks), I didn't dig deeper. But it turns out meson is setting the SONAME to "libopeniscsiusr.so.0"!
It also turns out I can manually set the SONAME in meson, so I *could* change the SONAME back to "libopeniscsiusr.so.0.2.0", but I don't think I want to do that. I think I was naming the SOLIB incorrectly before, and meson is doing it correctly.
So I will bite the bullet and change the name. If testing shows I can make it work. :)
Thank you again to everyone that replied!
Just to add again the link editor only records the SONAME into the object depending on the library so if you build against the 0.3.0 version, requiring the new ABI parts still only libopeniscsiusr0 gets recorded as dependence. That means libopeniscsiusr.so.0.1.0 will be considered fulfilling the dependence, also from the RPM side which auto-adds shared library dependences based on the SONAME (plus symbol versions appearing which could rectify this for openiscsiusr!). But then the application will likely still fail to dynamically link to libopeniscsiusr.so.0.1.0 in this case.
Richard.
The SONAME of libopeniscsiusr.so.0.1.0 was "libopeniscsiusr.so.0.1.0". Plus, the package dependencies make it difficult to have multiple versions of the library present. -- Lee