]> git.ipfire.org Git - thirdparty/ipset.git/commit
build: restore -version-info
authorJan Engelhardt <jengelh@inai.de>
Sun, 1 Jul 2012 18:36:19 +0000 (20:36 +0200)
committerJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Sun, 1 Jul 2012 20:44:36 +0000 (22:44 +0200)
commita1bd9d61b643da9e24ae53b7e321bc4d32c59e8f
tree534869e92d2c75e261dcfac9166334590e74c885
parent7c7b022a18ea2bae11d889b345caef87f3bf145e
build: restore -version-info

On Sunday 2012-07-01 19:20, Jozsef Kadlecsik wrote:
>[...]
>> * therefore the patch makes a clean restart,
>>   using -version-info 3:0:0, to continue using .so.3
>>   starting from ipset-6.13 until the next *real*
>>   incompatible change.
>
>What is still unclear for me, why a clean restart is required. Looking
>into "libtool", as I see, "-version-number 3:0:1" and "-version-info
>3:0:1" produces the same result.

They don't. The libtool manual goes on attempting to explain
"-version-number" with C:R:A, though it could have been a lot easier
to just say "it copies the values as-is to the file suffix".

---8<---
location git://git.inai.de/ipset (updated)

parent 7c7b022a18ea2bae11d889b345caef87f3bf145e (v6.13)
commit 2b145f0794de6f56eaded0a6403be995be98c93b
Author: Jan Engelhardt <jengelh@inai.de>
Date:   Sat Jun 30 20:39:27 2012 +0200

build: restore -version-info

Commit v6.13~7 accidentally swapped "-version-info" with
"-version-number". Because "-version-number" takes the values
"FIRST:AGE:REV", which is different from "-version-info
CURRENT:REV:AGE", libipset.so.3 was emitted.

Restore using "-version-info" and continue to use 3 as the "FIRST"
interface (instead of 2), because it was declared that way in
ipset-6.13.

Also note that the version names in libipset.map generally are not
supposed to follow SO versions, but the program version):
IPSET_6.13 {...}.

Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Make_global.am
lib/Makefile.am