search

doug-gilbert / sg3_utils

Author's own git mirror of his sg3_utils subversion repository. Note: default branch is now _main_. It includes tags from the various releases.
https://sg.danny.cz/sg/sg3_utils.html
Other
27 stars 22 forks source link

shared library SONAME #19

Open zeha opened 2 years ago

zeha commented 2 years ago

Hi,

thanks for maintaining sg3_utils. The build system also builds a libsgutils2-<version>.so.2.0.0, which is used by other software (ledmon, etc). Given the sg3_utils version number is embedded in the libsgutils2 SONAME, this causes the named other software to break on each sg3_utils version change.

Thus my question:

Thanks, Chris

doug-gilbert commented 2 years ago

libsgutils2 is intended to be public library but was not designed as such. Initially it was to save me duplicating code in each sg_* utility. I try not to change the interface of existing functions but sometimes T10 makes that difficult so I might add a _v2 variant. I think more about multi OS support, C and POSIX compliance than ABI stability. Plus I check it builds cleanly in C++ . I have noticed that runtime linking with shared objects can fail if a utility from version 1.45 say (e.g. sg_vpd) is run with the libsgutils2 from version 1.44 .

I'm no expert on SONAME and libtools but will take some guidance from the downstream RedHat and Suse maintainers if it can be improved. To date I don't remember getting any feedback from them on this issue.

zeha commented 2 years ago

I have noticed that runtime linking with shared objects can fail if a utility from version 1.45 say (e.g. sg_vpd) is run with the libsgutils2 from version 1.44 .

That would be expected, I think.

Debian wants to ship libsgutils2 (and currently does), because other software uses it. With the current SONAME format, everytime there is a new sg3_utils release, the SONAME changes. This causes a lot of work on the Debian side (new binary packages have to be introduced, all software using them has to be rebuilt, etc). Which is not ideal. BUT: if you are saying you do not have strong ABI stability checks in place, then maybe this is correct (for now)!

It really depends on what you want to do. If you can commit to ABI stability (and: if the ABI changes, changing the SONAME), then a manually managed, "stable" SONAME is a good thing. On the other hand, if the ABI can change maybe unexpectedly, then its better to keep the version number in the SONAME.