Re: [pcre-dev] PCRE2 10.20-RC1 available for testing

Top Page
Delete this message
Author: Petr Pisar
Date:  
To: pcre-dev
Subject: Re: [pcre-dev] PCRE2 10.20-RC1 available for testing
On Fri, Jun 19, 2015 at 03:33:27PM +0100, ph10@??? wrote:
> On Fri, 19 Jun 2015, Petr Pisar wrote:
> > But the only thing which puzzles me is why the libpcre2_{8.16,32}'s soname
> > was changed from 0 to 2. I cannot se any incompatible change in API and
> > ABI. Is it because of the EBCDIC behavior change which is not visible with
> > --disable-ebcdic compile-time option?
>
> The "rules" that I have for changing the soname are these (I found them on
> a web page some time ago):
>
> 1. Start with version information of 0:0:0 for each libtool library.
>
> 2. Update the version information only immediately before a public release
> of your software. More frequent updates are unnecessary, and only guarantee
> that the current interface number gets larger faster.
>
> 3. If the library source code has changed at all since the last update, then
> increment revision; c:r:a becomes c:r+1:a.
>
> 4. If any interfaces have been added, removed, or changed since the last
> update, increment current, and set revision to 0.
>
> 5. If any interfaces have been added since the last public release, then
> increment age.
>
> 6. If any interfaces have been removed or changed since the last public
> release, then set age to 0.
>
> It was rule 5 that I was following: the new function
> pcre2_callout_enumerate() has been added.
>

I know the libtool rules. The rule 5 means to increase age, the last value.
While you increased the only current, the first value:

-m4_define(libpcre2_8_version,     [1:0:1])
-m4_define(libpcre2_16_version,    [1:0:1])
-m4_define(libpcre2_32_version,    [1:0:1])
+m4_define(libpcre2_8_version,     [2:0:0])
+m4_define(libpcre2_16_version,    [2:0:0])
+m4_define(libpcre2_32_version,    [2:0:0])


I think the correct value should be 2:0:2 because you have to apply rules 3,
4, and 5.

That way the soname will be preserved, so applications built against old
library will still work with the new library because the new library is
backward compatible with the old one. Otherwise anybody who upgrades from
10.10 to 10.20 whould have to rebuild all his applications.

Speaking of symlinks for ld-linux.so, the previous state was:

/usr/lib64/libpcre2-8.so -> libpcre2-8.so.0.1.0
/usr/lib64/libpcre2-8.so.0 -> libpcre2-8.so.0.1.0
/usr/lib64/libpcre2-8.so.0.1.0

The RC-1 state is now:

/usr/lib64/libpcre2-8.so -> libpcre2-8.so.2.0.0
/usr/lib64/libpcre2-8.so.2 -> libpcre2-8.so.2.0.0
/usr/lib64/libpcre2-8.so.2.0.0

While I propose:

libpcre2-8.so -> libpcre2-8.so.0.2.0
libpcre2-8.so.0 -> libpcre2-8.so.0.2.0
libpcre2-8.so.0.2.0


-- Petr