On Tue, Nov 18, 2025 at 1:52 PM Branko Čibej <[email protected]> wrote:
> On 18. 11. 25 09:22, Timofei Zhakov wrote: > > On Mon, Nov 17, 2025 at 12:13 AM Branko Čibej <[email protected]> wrote: > >> On 16. 11. 25 17:05, Daniel Sahlberg wrote: >> >> Den tis 12 aug. 2025 kl 18:56 skrev notroj (via GitHub) <[email protected]>: >> >>> >>> notroj opened a new pull request, #34: >>> URL: https://github.com/apache/subversion/pull/34 >>> >>> ``` >>> * configure.ac: Pass complete library version information to libtool >>> via $SVN_LT_SOVERSION, so library filenames are unique to each >>> release rather than constant, while keeping the sonames intact. >>> >>> Examples for SVN 1.14.5: >>> Filename before: libsvn_subr-1.so.0.0.0 >>> Filename after: libsvn_subr-1.so.0.14.5 >>> SONAME before and after: libsvn_subr-1.so.0 >>> ``` >>> >>> >>> -- >>> This is an automated message from the Apache Git Service. >>> To respond to the message, please log on to GitHub and use the >>> URL above to go to the specific comment. >>> >>> To unsubscribe, e-mail: [email protected] >>> >>> For queries about this service, please contact Infrastructure at: >>> [email protected] >>> >>> >> This has been laying open in GitHub for far too long. Anyone keen on >> reviewing this? It is unfortunately far out of my comfort zone. >> >> >> Changing the SOVERSION is a potential backwards-compatibility issue, we >> can't do this in a patch release. Should be fine to do this on trunk only >> and release it with 1.15. I think. Someone with more ELF-fu should chime >> in. Doesn't help that the SONAME is 0 instead of 1, but we can't fix that >> before 2.0. >> >> We have a similar issue on MacOS, where we set the dylib >> current-version and compatibility-version both to 1.0.0, but the former >> could/should be the actual release version. >> >> How does the CMake build do with regards to filenames/sonames? >> >> >> Has to be done explicitly. CMake has variables to set that globally for a >> project. >> >> -- Brane >> >> > According to my research, the majority of libraries use this naming where > they include version after .so part instead of triple-zero. So, I think we > should stick with this style. > > However, I agree with Branko that such change has to be made in a minor > release rather than a patch, since it might change the ABI. > > An example of such naming: > ``` > $ ls /usr/lib/x86_64-linux-gnu/ > > [...] > libkwalletbackend5.so > libkwalletbackend5.so.5 > libkwalletbackend5.so.5.92.0 > [...] > ``` > > In cmake it could be done by setting the SOVERSION property of each > target. Also our cmake exposes the SVN_SOVERSION variable which in current > implementation sets only the major version. > > > Does that mean it creates libsvn_foo-1.so.1.0.0? If so, that's > incompatible with the autotools build. > > My bad, it defaults to just a zero, since it is an ABI version. Major version goes after the library name with a leading dash (libsvn_foo*-1*.so.0.0.0). Exactly the same as the autoconf build. ``` set(SVN_SOVERSION "0" CACHE STRING "Subversion library ABI version") ``` > I would suggest introducing a similar option to the autoconf generator so > users may customise it for their needs (for example, Debian distribution > might want to keep old naming for backward compatibility). This will also > allow introducing this change in a patch release. > > > > Downstream packagers can patch the source if they want different SOVERSION > or SONAME. That's really not our problem to solve. > Yes, but they should not end up in a situation where the build output format changes in new versions. That's why I stick with the "option" approach. On the other hand, if we agree that it was just a minor bug, it should be fine IMO. It's not a big deal. > > To summarise, I think we should first question ourselves whether it is > worth it to even make this change, which potentially violates backward > compatibility guidelines. But I generally support this change. > > [1] https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html > > -- Timofei Zhakov
