How to correctly package my Shared Library: shlib-policy-name-error ???
Hi: I maintain the open-iscsi package. It delivers the PRMs: - libopeniscsiusr0_2_0 - open-iscsi-2.1.8 - open-iscsi-devel-2.1.8 My problem is with libopeniscsiusr0_2_0. And this problem only seems to occur on SUSE's Internal Build Service, but I'm hoping you can help anyway. My libopeniscsiusr package has only two files in it: a shared library, and a symlink to that library. Here are the two after %build:
lrwxrwxrwx 1 lduncan 24 Dec 9 12:21 libopeniscsiusr.so.0 -> libopeniscsiusr.so.0.2.0* -rwxr-xr-x 1 lduncan 143424 Dec 9 12:21 libopeniscsiusr.so.0.2.0*
So libopeniscsiusr.so.0 is a symlink to libopeniscsiusr.so.0.2.0, the real shared library. [A development package adds the "libopeniscsiusr.so" symlink] In my RPM SPEC file, I specify the files in the library RPM like this:
%files -n libopeniscsiusr0_2_0 %{_libdir}/libopeniscsiusr.so.*
And when the RPM is built and I examine it (or install it), sure enough the package is installed correctly, in /usr/lib64, i.e. libopeniscsiusr.so.0 is a symlink to libopeniscsiusr.so.0.2.0. As I said, our open build service handles this fine. But when I submit this same package to SUSE for SLE, it complains:
[ 117s] libopeniscsiusr0_2_0.x86_64: E: shlib-policy-name-error (Badness: 10000) libopeniscsiusr0 [ 117s] Your package contains a single shared library but is not named after its [ 117s] SONAME.
So it _looks_ like it's suggesting the package be named "libopeniscsiusr0"? But the "libopeniscsiusr0" file is just a symlink. By the way, my package has been like this for a couple of year in SLE, so I'm not sure why it's complaining. Help? -- Lee Duncan
Hi Lee! On 12/9/22 23:24, Lee Duncan wrote:
As I said, our open build service handles this fine. But when I submit this same package to SUSE for SLE, it complains:
[ 117s] libopeniscsiusr0_2_0.x86_64: E: shlib-policy-name-error (Badness: 10000) libopeniscsiusr0 [ 117s] Your package contains a single shared library but is not named after its [ 117s] SONAME.
So it _looks_ like it's suggesting the package be named "libopeniscsiusr0"? But the "libopeniscsiusr0" file is just a symlink.
As far as I know, ABI version numbers are normally single digit so that your package should be indeed named "libopeniscsiusr0" and not "libopeniscsiusr0_2_0". I don't remember having seen any library package that has a non-single-digit version number in its name. Adrian
On 12/9/22 14:34, John Paul Adrian Glaubitz wrote:
Hi Lee!
On 12/9/22 23:24, Lee Duncan wrote:
As I said, our open build service handles this fine. But when I submit this same package to SUSE for SLE, it complains:
[ 117s] libopeniscsiusr0_2_0.x86_64: E: shlib-policy-name-error (Badness: 10000) libopeniscsiusr0 [ 117s] Your package contains a single shared library but is not named after its [ 117s] SONAME.
So it _looks_ like it's suggesting the package be named "libopeniscsiusr0"? But the "libopeniscsiusr0" file is just a symlink.
As far as I know, ABI version numbers are normally single digit so that your package should be indeed named "libopeniscsiusr0" and not "libopeniscsiusr0_2_0".
I don't remember having seen any library package that has a non-single-digit version number in its name.
Adrian
Thank you for your reply! I believe you are likely correct. I did more online OBS packaging guidelines research, and it looks like that is what is done. But in my case, this library had an older version: old: libopeniscsiusr.so.0.1.0 new: libopeniscsiusr.so.0.2.0 No interfaces went away, but new ones were added. FWIW. So, bottom line, if I change this package name from libopeniscsiusr0_2_0 to libopeniscsiusr0, how will I handle the new version update, i.e. when libopeniscsiusr0_3_0 comes out? (If it ever does) Also, if I change the name, won't I need an "obsoletes" clause in the updated SPEC file? And what about "Provides" to cover the library package name I'm "removing" (renaming) e.g.:
%package -n libopeniscsiusr0 Version: 2.1.8 Release: 0 Summary: The iSCSI User-level Library Group: System/Libraries Obsoletes: libopeniscsiusr0_1_0 Obsoletes: libopeniscsiusr0_2_0 # Is this one needed? Provides: libopeniscsiusr0_2_0
-- Lee D
On Freitag, 9. Dezember 2022 23:54:31 CET Lee Duncan wrote:
On 12/9/22 14:34, John Paul Adrian Glaubitz wrote:
Hi Lee!
On 12/9/22 23:24, Lee Duncan wrote:
As I said, our open build service handles this fine. But when I submit
this same package to SUSE for SLE, it complains:
[ 117s] libopeniscsiusr0_2_0.x86_64: E: shlib-policy-name-error (Badness: 10000) libopeniscsiusr0 [ 117s] Your package contains a single shared library but is not named after its [ 117s] SONAME.
So it _looks_ like it's suggesting the package be named "libopeniscsiusr0"? But the "libopeniscsiusr0" file is just a symlink.
As far as I know, ABI version numbers are normally single digit so that your package should be indeed named "libopeniscsiusr0" and not "libopeniscsiusr0_2_0".
I don't remember having seen any library package that has a non-single-digit version number in its name.
Adrian
Thank you for your reply! I believe you are likely correct. I did more online OBS packaging guidelines research, and it looks like that is what is done.
https://en.opensuse.org/ openSUSE:Shared_library_packaging_policy#Versioning_schemes
But in my case, this library had an older version:
old: libopeniscsiusr.so.0.1.0 new: libopeniscsiusr.so.0.2.0
No interfaces went away, but new ones were added. FWIW.
So, bottom line, if I change this package name from libopeniscsiusr0_2_0 to libopeniscsiusr0, how will I handle the new version update, i.e. when libopeniscsiusr0_3_0 comes out? (If it ever does)
Dependency tracking for shared libraries is done automatically. Have a look at either the package "Details" on the OBS, or use "rpm -qp --provides <rpm- file>". The *only* correct way to handle ABI updates which are backwards compatible is by using symbol versioning. Such a package provides the library with an ABI version number, and the same with additional tags covering the extended ABI. Any user of the extended ABI will also depend on these additional tags.
Also, if I change the name, won't I need an "obsoletes" clause in the updated SPEC file? And what about "Provides" to cover the library
You need a "Conflicts:" towards the old, incorrectly named file, because both packages contain the same files. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On 12/9/22 23:54, Lee Duncan wrote:
Thank you for your reply! I believe you are likely correct. I did more online OBS packaging guidelines research, and it looks like that is what is done.
But in my case, this library had an older version:
old: libopeniscsiusr.so.0.1.0 new: libopeniscsiusr.so.0.2.0
No interfaces went away, but new ones were added. FWIW.
So, bottom line, if I change this package name from libopeniscsiusr0_2_0 to libopeniscsiusr0, how will I handle the new version update, i.e. when libopeniscsiusr0_3_0 comes out? (If it ever does)
If the major version number remains 0, the ABI versions should be compatible with each other and no version bump should be necessary.
Also, if I change the name, won't I need an "obsoletes" clause in the updated SPEC file?
Normally, all reverse dependencies would have to be rebuilt in OBS. This way, the library dependencies are updated automatically. So there is no need to use Provides/Obsoletes. It's only important that the name of the -devel package remains unchanged but that's usually the case because it's normally without an ABI version as it should. Adrian
Hi Lee!
On 12/9/22 23:24, Lee Duncan wrote:
As I said, our open build service handles this fine. But when I submit
On Freitag, 9. Dezember 2022 23:34:39 CET John Paul Adrian Glaubitz wrote: this same package to SUSE for SLE, it complains:
[ 117s] libopeniscsiusr0_2_0.x86_64: E: shlib-policy-name-error (Badness: 10000) libopeniscsiusr0 [ 117s] Your package contains a single shared library but is not named after its [ 117s] SONAME.
So it _looks_ like it's suggesting the package be named "libopeniscsiusr0"? But the "libopeniscsiusr0" file is just a symlink.
The SONAME of the library is "libopeniscsiusr.so.0", and thats what matters.
As far as I know, ABI version numbers are normally single digit so that your package should be indeed named "libopeniscsiusr0" and not "libopeniscsiusr0_2_0".
As far as the linker is concerned, the SONAME is just a string. Depending on the project, the SONAME may include one or more numbers. The position of the numbers does not matter much, foobar.so.1 is as good as foobar-1.so. (Though, occasionaly you find libraries without any numbers, which is bad).
I don't remember having seen any library package that has a non-single-digit version number in its name.
There are plenty. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On 12/10/22 00:46, Stefan Brüns wrote:
So it _looks_ like it's suggesting the package be named "libopeniscsiusr0"? But the "libopeniscsiusr0" file is just a symlink.
The SONAME of the library is "libopeniscsiusr.so.0", and thats what matters.
True.
As far as I know, ABI version numbers are normally single digit so that your package should be indeed named "libopeniscsiusr0" and not "libopeniscsiusr0_2_0".
As far as the linker is concerned, the SONAME is just a string. Depending on the project, the SONAME may include one or more numbers. The position of the numbers does not matter much, foobar.so.1 is as good as foobar-1.so. (Though, occasionaly you find libraries without any numbers, which is bad).
Agreed.
I don't remember having seen any library package that has a non-single-digit version number in its name.
There are plenty.
Yes, OK. However, openSUSE does seem to use three-digit ABI version numbers when other distributions don't. This is what confused me. For example, the current version of libprotobuf: - openSUSE - libprotobuf3_21_11 - Debian/Ubuntu - libprotobuf32 - Mageia - libprotobuf30 Or libimobiledevice: - openSUSE - libimobiledevice-1_0-6 - Debian/Ubuntu - libimobiledevice6 - Mageia - libimobiledevice - Fedora - libimobiledevice Or libavcodec from ffmpeg: - openSUSE - libavformat58_76 - Debian/Ubuntu - libavcodec58 - Fedora - libavcodec-free Adrian
On Saturday 2022-12-10 19:04, John Paul Adrian Glaubitz wrote:
Yes, OK. However, openSUSE does seem to use three-digit ABI version numbers when other distributions don't. This is what confused me.
For example, the current version of libprotobuf:
- openSUSE - libprotobuf3_21_11 - Debian/Ubuntu - libprotobuf32 - Mageia - libprotobuf30
Someone cherry-picked some git commit or something that changed -version-info to -release. From 15daef3b7912b9434955a8614e018de00591aefb Mon Sep 17 00:00:00 2001 From: Deanna Garcia <deannagarcia@google.com> Date: Wed, 3 Aug 2022 17:40:03 +0000 Subject: [PATCH 1/2] Use release version instead of libtool version [ 332s] libtool: install: /usr/bin/install -c .libs/libprotobuf-3.21.11.so
Or libimobiledevice:
- openSUSE - libimobiledevice-1_0-6 - Debian/Ubuntu - libimobiledevice6 - Mageia - libimobiledevice - Fedora - libimobiledevice
openSUSE build log: -pthread -Wl,-soname -Wl,libimobiledevice-1.0.so.6 Debian just does not give a lot of care to its package naming here. If there was both a libimobiledevice-1.0.so.6 and a libimobiledevice-2.0.so.6 file, there'd be a problem on Debian. Fedora does not care about SLPP at all.
Or libavcodec from ffmpeg:
- openSUSE - libavformat58_76 - Debian/Ubuntu - libavcodec58 - Fedora - libavcodec-free
Like case 1 above. When the SONAME changes via a patch for any particular reason, the package build recipe has to follow suit.
On 10.12.2022 01:34, John Paul Adrian Glaubitz wrote:
Hi Lee!
On 12/9/22 23:24, Lee Duncan wrote:
As I said, our open build service handles this fine. But when I submit this same package to SUSE for SLE, it complains:
[ 117s] libopeniscsiusr0_2_0.x86_64: E: shlib-policy-name-error (Badness: 10000) libopeniscsiusr0 [ 117s] Your package contains a single shared library but is not named after its [ 117s] SONAME.
So it _looks_ like it's suggesting the package be named "libopeniscsiusr0"? But the "libopeniscsiusr0" file is just a symlink.
As far as I know, ABI version numbers are normally single digit so that your package should be indeed named "libopeniscsiusr0" and not "libopeniscsiusr0_2_0".
Wrong. Package name must match library SONAME which can be anything.
I don't remember having seen any library package that has a non-single-digit version number in its name.
https://build.opensuse.org/package/view_file/openSUSE:Factory/open-iscsi/ope... %package -n libopeniscsiusr0_2_0 Version: 2.%{iscsi_minor_release}.%{iscsi_patch_release} Release: 0 Summary: The iSCSI User-level Library Group: System/Libraries Obsoletes: libopeniscsiusr0_1_0 < %{version} I have no idea why it fails on SUSE internal server.
On 12/10/22 07:59, Andrei Borzenkov wrote:
As far as I know, ABI version numbers are normally single digit so that your package should be indeed named "libopeniscsiusr0" and not "libopeniscsiusr0_2_0".
Wrong. Package name must match library SONAME which can be anything.
Using a single-digit is the commonly used mechanism, quoting [1]:
So it doesn't really matter for the parts of the shared library that aren't part of the SONAME. The libtool convention and the semantic versioning convention both make the first integer after the .so portion of the name the version for incompatible changes, which both do the same thing. Since that's the portion that's usually in the SONAME, they're equivalent for this purpose.
I mentioned that some shared libraries do different things. For example, OpenSSL has libssl.so.1.1 and libcrypto.so.1.1 as the shared library SONAMEs it uses. While this is not the recommended convention, it happens to work. They're changing to semantic versioning in future versions, though, because people find this confusing.
In Lee's case, adding additional functions does not break the ABI and hence a bump of the SOVERSION is not necessary. See "3.6. Incompatible Libraries" [2].
I don't remember having seen any library package that has a non-single-digit version number in its name.
https://build.opensuse.org/package/view_file/openSUSE:Factory/open-iscsi/ope...
%package -n libopeniscsiusr0_2_0
Well, that's Lee's package we are currently talking about.
I have no idea why it fails on SUSE internal server.
Because it's using stricter rules for it's packaging sanity checks. Adrian
[1] https://stackoverflow.com/questions/7553184/how-to-do-versioning-of-shared-l... [2] https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
On 10.12.2022 10:37, John Paul Adrian Glaubitz wrote:
On 12/10/22 07:59, Andrei Borzenkov wrote:
As far as I know, ABI version numbers are normally single digit so that your package should be indeed named "libopeniscsiusr0" and not "libopeniscsiusr0_2_0".
Wrong. Package name must match library SONAME which can be anything.
Using a single-digit is the commonly used mechanism, quoting [1]:
May be you should start with own guidelines instead of referring to the third-party posts https://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Package_nam... ...
In Lee's case, adding additional functions does not break the ABI and hence a bump of the SOVERSION is not necessary. See "3.6. Incompatible Libraries" [2].
This is irrelevant for this discussion. The reason for this error is that package name does not match SONAME. SONAME is libopeniscsiusr.so.0, so package must be named libopeniscsiusr0. Whether the SONAME itself is set correctly is the question to library developer, not to the library packager.
I don't remember having seen any library package that has a non-single-digit version number in its name.
libcdrdeflt1_0 libmythes-1_2-0 libpng16-16 just the first several random libraries installed here. I do not mean that your recommendation was incorrect. But it is also important to understand *why* library package has to be named this way for the future. The reason "because it needs just major number" is not correct from the packaging point of view. It may be relevant for developer to chose the SONAME. ...
I have no idea why it fails on SUSE internal server.
Because it's using stricter rules for it's packaging sanity checks.
Interesting. I am pretty sure I have seen this error in the openSUSE builds, but may be I am mistaken.
On 12/10/22 10:09, Andrei Borzenkov wrote:
May be you should start with own guidelines instead of referring to the third-party posts
https://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Package_nam...
...
What's the point in changing the package name when the ABI change is a compatible one? https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html (see Section 3.6) The whole point of encoding the SOVERSION in the package name is to indicate whether two versions of a shared library have a compatible ABI or not. That's also the reason why there is a libfoo.so.1 even when the full version is 1.2.3. This is also true for
libcdrdeflt1_0 libmythes-1_2-0 libpng16-16
just the first several random libraries installed here.
Three examples out of how many?
I do not mean that your recommendation was incorrect. But it is also important to understand *why* library package has to be named this way for the future. The reason "because it needs just major number" is not correct from the packaging point of view. It may be relevant for developer to chose the SONAME.
Again, the point of using SONAME is to indicate whether two library packages are ABI-compatible. If that above SCSI library ABI version changes from 0.2.0 to 0.3.0 without breaking the ABI, it makes no sense to bump the ABI version for that. Adrian
On Saturday 2022-12-10 10:09, Andrei Borzenkov wrote:
I have no idea why it fails on SUSE internal server.
Because it's using stricter rules for it's packaging sanity checks.
Interesting. I am pretty sure I have seen this error in the openSUSE builds, but may be I am mistaken.
"SUSE internal server" may be a misnomer referring to "SLE12 build target", where an old rpmlint was used that just does the checks not quite right.
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! -- Lee Duncan
On 12/10/22 11:08, 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"!] ^^^^^ Sorry, typo! this was supposed to be "...0.1.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!
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. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
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
On 12/11/22 09:29, Lee Duncan wrote:
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.
But I understand your point, I believe, as far as compatibility going forward. Luckily this library won't likely be updated any time soon. Thanks again. -- Lee
Hi Lee, On Sat, 2022-12-10 at 11:08 -0800, 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!
If I understand correctly, you have decided to change the SONAME and the package name to "libopeniscsiusr.so.0" and "libopeniscsiusr0", respectively. I don't think this is a good idea after the previous package had "libopeniscsiusr.so.0.1.0" and "libopeniscsiusr0_1_0". I would recommend you stick to the same SONAME naming scheme that was originally used. So, if the ABI is still compatible and the SONAME changes was really just introduced by the switch to meson, you could just keep the previous SONAME "libopeniscsiusr.so.0.1.0". If the ABI is incompatible, switching to "libopeniscsiusr.so.0.2.0" makes more sense than switching to "libopeniscsiusr.so.0". In my experience, ".0" is usually just a lazy persons's SONAME, basically equivalent to saying "we are not tracking SONAME properly". It's true that the SONAME is just a string, but it's also being read by human beings, which tend to interpret it similar to a version number. As others have suggested, the alternative would be switching to proper symbol versioning in the upstream library. But that would be an extra upstream development effort. Martin
On 12/12/22 03:33, Martin Wilck wrote:
Hi Lee,
On Sat, 2022-12-10 at 11:08 -0800, 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!
If I understand correctly, you have decided to change the SONAME and the package name to "libopeniscsiusr.so.0" and "libopeniscsiusr0", respectively.
Correct.
I don't think this is a good idea after the previous package had "libopeniscsiusr.so.0.1.0" and "libopeniscsiusr0_1_0".
The previous version of this package (before meson) had "libopeniscsiuio.so.0.2.0" and "libopeniscsiusr0_2_0". Before that, with the previous library (a few years ago?), it was "libopeniscsiusr.so.0.2.0" and "libopeniscsiusr0_2_0". The question of the SONAME boils down to this: it should change when the APIs of the library change, as far as I understand. Indeed, going from 0.1.0 to 0.2.0, new APIs were added. So the SONAME needed to change (and it did). There are no new changes planned for the library, so it'll probably be 0.2.0 for a while.
I would recommend you stick to the same SONAME naming scheme that was originally used. So, if the ABI is still compatible and the SONAME changes was really just introduced by the switch to meson, you could just keep the previous SONAME "libopeniscsiusr.so.0.1.0". If the ABI is incompatible, switching to "libopeniscsiusr.so.0.2.0" makes more sense than switching to "libopeniscsiusr.so.0". In my experience, ".0" is usually just a lazy persons's SONAME, basically equivalent to saying "we are not tracking SONAME properly". It's true that the SONAME is just a string, but it's also being read by human beings, which tend to interpret it similar to a version number.
First of all, this is already pushed to the OBS and submitted to IBS. Second, I believe the correct SONAME should be "libopeniscsiusr.so.0", so I'd like to use that going forward. Of course that will change when (and if) the library APIs change again. Lastly, there are a lot of library versioning/naming schemes out there, and I hardly think using a single number is lazy. But in fact we do not use a single number here -- upstream chose the MAJOR.MINOR.SUB numbering scheme.
As others have suggested, the alternative would be switching to proper symbol versioning in the upstream library. But that would be an extra upstream development effort.
Yes, I have that on my list of things to do, but I'm not sure how to do it correctly. Right now, there is no definitive list of the APIs in the library except in the header file. So the build actually makes man pages from the header file. This way, if and when new APIs are added, it's all handled automatically. If I make a static list of the APIs it will add to the steps needed to be taken when adding a new API. But then again, as I said, new APIs are not common in this library. Still, I don't want to add more work. :) Bottom line I'll probably just make a static list for versioning the APIs, but I just haven't gotten to it. (Partly because nobody cares and it would have little actual benefit right now.) But please feel free to submit a pull request. :)
Martin
participants (7)
-
Andrei Borzenkov -
Jan Engelhardt -
John Paul Adrian Glaubitz -
Lee Duncan -
Martin Wilck -
Richard Biener -
Stefan Brüns