On Mon, Jun 23, 2025 at 02:29:46PM +0200, Branko Čibej wrote: > On 23. 6. 25 11:48, Joe Orton wrote: > > On Mon, Jun 23, 2025 at 10:31:54AM +0200, Daniel Sahlberg wrote: > > > Serf never had an autoconf build system (oh, Greg will surely grey-beard > > > me > > > on that one, we had one but it was removed by him in r1699088 back in > > > 2011). Maybe there were/are differences between SCons and CMake when it > > > comes to soname (as well...). > > > > > > I'd consider it a bug with the CMake build system (unless thoroughly > > > convinced otherwise) if it creates stuff that is different from the SCons > > > system. > > Right, it used autoconf even in the 1.2.x releases? If I build pristine > > serf from upstream 1.3.x today with scons it uses a libserf-1.so.1 > > soname. Using the autoconf build system as shipped with serf 1.0 thru > > 1.2.x gave us libserf-1.so.0. I assume the soname bump was not intended > > without an ABI break. > > Turns out that the autoconf build didn't do anything about the soname and > just let libtool do whatever its default behaviour was. No, the version bump > was not intended. I guess we just have to live with it. > > I'm not too familiar with how soversion works: would adding a symlink from > .0.so -> .1.so help in any way? Or a copy of the library? Or do we have to > relink the library, albeit from the same sources? Such a fix could easily be > added in a patch 1.3.x release (if we ever get around to making one), though > not in the non-existent CMake build on that branch.
I think the simplest fix would be to create a stub libserf-1.so.0 with that soname, which is empty but links to libserf-1.so.1. TBH I would leave this to any distro packagers to deal with, that is the only context where people really care about this. Regards, Joe
