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. 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 -Robert Middleton
