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 <http://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.
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.
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
