On Sat, Dec 31, 2022 at 10:38:37AM -0500, Robert Middleton wrote: > On Sat, Dec 31, 2022 at 4:22 AM Tobias Frost <t...@debian.org> wrote: > > The generated file names look strange: > > > > Now: > > tobi@isildor:~/workspace/deb/packages/log4cxx/upstream/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ > > ls -la liblog4cxx* > > lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:51 liblog4cxx.so -> > > liblog4cxx.so.15.0.0 > > -rw-r--r-- 1 tobi tobi 22632496 Dec 31 08:50 liblog4cxx.so.1.0.0.0 > > lrwxrwxrwx 1 tobi tobi 21 Dec 31 08:51 liblog4cxx.so.15.0.0 -> > > liblog4cxx.so.1.0.0.0 > > > > I'd expect the (actually) library be liblog4cxx.so.15.0.0 and symlinks > > pointing to it: > > liblog4cxx.so --> liblog4cxx.so.15 --> liblog4cxx.so.15.0.0 > > (linker name) --> (soname) --> (real name) > > > > (References: > > https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, > > https://man7.org/conf/lca2006/shared_libraries/slide5b.html and following > > slides) > > > > before it was like this, which matches what I see on other libraries and > > what I would expect: > > tobi@isildor:~/workspace/deb/packages/log4cxx/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ > > ls -la liblog4cxx* > > total 22780 > > lrwxrwxrwx 1 tobi tobi 16 Dec 31 08:55 liblog4cxx.so -> > > liblog4cxx.so.13 > > lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:55 liblog4cxx.so.13 -> > > liblog4cxx.so.13.0.0 > > -rw-r--r-- 1 tobi tobi 23308784 Dec 31 08:54 liblog4cxx.so.13.0.0 > > ) > > > > (If you want to encode the project version into the name, it would be more > > liblog4cxx-1.0.0.so, liblog4cxx-1.0.0.so.15 and sliblog4cxx-1.0.0.so.15.0.0 > > , but that's breaking > > the concept of soanmes alltogether, as for the linker/loader > > liblog4cxx-1.0.0.so.15 and liblog4cxx-1.0.1.so.15 would > > be different, unrelated libraries) > > FWIW my reference is mostly from this (old) thread on the KDE mailing > list: https://mail.kde.org/pipermail/kde-buildsystem/2008-April/004543.html > This would seem to agree with the TLDP documentation, which states: > "Every shared library has a special name called the ``soname''. The > soname has the prefix ``lib'', the name of the library, the phrase > ``.so'', followed by a period and a version number that is incremented > whenever the interface changes (as a special exception, the > lowest-level C libraries don't start with ``lib''). A fully-qualified > soname includes as a prefix the directory it's in; on a working system > a fully-qualified soname is simply a symbolic link to the shared > library's ``real name''. > > Every shared library also has a ``real name'', which is the filename > containing the actual library code. The real name adds to the soname a > period, a minor number, another period, and the release number. The > last period and release number are optional. The minor number and > release number support configuration control by letting you know > exactly what version(s) of the library are installed. Note that these > numbers might not be the same as the numbers used to describe the > library in documentation, although that does make things easier." > > So setting the SONAME to 15.0.0 results in the liblog4cxx.so.15, with > a version of 1.0.0.0(liblog4cxx.so.1.0.0.0) which would correspond to > the correct log4cxx version in this case(CMake allows for > major.minor.patch.tweak, but for the human-readable release I do just > major.minor.patch). As far as I can tell, the important thing is that > the SONAME does not always equal the version name(if we were following > semantic versioning earlier it probably would be the same), but that's > part of this release to get it into a state where the versions and > SONAME should increment independently of each other.
(sorry for being short worded, not having much time right now) Please note that library versioning has nothing do do with project versioning, don't conflate them… It is a sign of improper library versioning if the project has the same version as the library. IOW, so name versioning do not follow semantic versioning. I still believe that the real name needs to be liblog4cxx.15.0.0, and this also matches my experience how it is done generally. I pretty please ask not to deviate from that, libraries are very easily made so that they are subtly break, and my experience shows that your are always best of by following established practices. BTW, I'm getting a (new) lintian warning [0] W: liblog4cxx15: package-name-doesnt-match-sonames liblog4cxx15.0.0 readelf -a liblog4cxx.so.1.0.0.0 | grep SONAME 0x000000000000000e (SONAME) Library soname: [liblog4cxx.so.15.0.0] compare that to eg. of libpng: readelf -a /usr/lib/x86_64-linux-gnu/libpng16.so.16.39.0 | grep SONAME 0x000000000000000e (SONAME) Library soname: [libpng16.so.16] I think there is something broken, ENOTIME to investiate right now, probably SO version* is set to 15.0.0 instead of only 15. * sorry for the non-exact wording… [0] https://lintian.debian.org/tags/package-name-doesnt-match-sonames > Anyway, I'm going to do the following: > * Update the changelog for this new release > * Make sure the ABI dump is up to date(only needed for builds on > github, this is not in the release tarball) > * Merge next_stable into master and delete next_stable, so that master > becomes the new master > * Call a release vote Please lets first fix the SONAME issue… This is something which has a huge impact and having the need to have a Debian specific patch here would be really bad. > -Robert Middleton -- tobi
