FS#54470 - [libconfig] libtool versioning issue with 1.6
Attached to Project:
Arch Linux
Opened by userwithuid (userwithuid) - Friday, 16 June 2017, 00:03 GMT
Last edited by Antonio Rojas (arojas) - Friday, 16 June 2017, 18:53 GMT
Opened by userwithuid (userwithuid) - Friday, 16 June 2017, 00:03 GMT
Last edited by Antonio Rojas (arojas) - Friday, 16 June 2017, 18:53 GMT
|
Details
Arch's new libconfig 1.6 has a lower .so version:
deb libconfig 1.3.2 -> libconfig.so.8.0.0 (from old debian as an example) arch libconfig 1.5.3 -> libconfig.so.9.2.0 arch libconfig 1.6 -> libconfig.so.8.3.1 This is because arch now uses autoreconf to regenerate *.in but lib/Makefile.{am,in} have a discrepancy wrt the libtool -version-info string. This was already reported upstream: https://github.com/hyperrealm/libconfig/issues/61 Not sure what the best course of action is. Ideally upstream would set a proper version, but upstream looks quite dead. Most other distros stick with 1.5. Going down to so.8 looks like the worst option though, so I suggest using 9.3.0 to keep with the spirit of lib versions. ABI seems to be backwards-compatible => no soname bump, but there are new public functions => bump second number. Patch is trivial, just replace "-version-info 11:1:3" in lib/Makefile.am with "-version-info 12:0:3". |
This task depends upon
Closed by Antonio Rojas (arojas)
Friday, 16 June 2017, 18:53 GMT
Reason for closing: Fixed
Additional comments about closing: libconfig 1.6-2
Friday, 16 June 2017, 18:53 GMT
Reason for closing: Fixed
Additional comments about closing: libconfig 1.6-2
Aside from that:
2. As usual with "new" sonames, you lose (possible) bin-compat with any 3rd-party binary built against the "old" ABI, in this case anything built against libconfig on any distro for the last few years (and probably the next 5 years since libconfig upstream seems dead so ABI can't change much). Also, stuff build against the old not-fake so.8 would probably crash. To be fair though, I'm not sure how widespread libconfig usage really is. And this is probably just stating the obvious about sonames that everyone already knows.
3. This issue with the wrong 8.3.1 version only exists in the first place because of the way Arch (you?) fixed the other upstream issue (with scanner.{l,c,h}), namely by using autoreconf. Check out for example this [0] way, which seems to compile but still preserve 9.2.0. Or how this [1] small distro noticed the issue as well and just patched it to use 9.3.0. I guess I should have searched harder, I could have linked this in the OP...
I mean sure, you have now partially worked around that upstream bug by rebuilding arch deps. But isn't it better to just keep in sync with every other distro out there (the 99% still on 1.5 AND the, like, 3 that have 1.6 but kept so.9), especially when the fix is so trivial? Also, it would be correct, did I mention that? :-P
[0] https://github.com/KaOSx/main/blob/1bcf7c8d1a973bbae190f93ddf6b7042a0b3eabb/libconfig/PKGBUILD
[1] https://git.pld-linux.org/gitweb.cgi?p=packages/libconfig.git;a=commitdiff;h=37623e97c8f4341e9d640284e90ec7661ba784a9