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