------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1207
--- Comment #1 from Philip Hazel <ph10@???> 2012-02-06 09:57:07 ---
On Sun, 5 Feb 2012, Juergen Daubert wrote:
> With version 8.21 the soname is libpcre.so.0.0.1 which means that everything
> that is linked with libpcre must be recompiled against the new version. I don't
> think that this is intended nor necessary.
I think it is, strictly, necessary. The function pcre_info(), which has
been obsolete for 10 years, was removed from the API. It did not seem
sensible to perpetuate the obsolescence by inventing a matching
pcre16_info(). Any program that still uses pcre_info() will fail with
8.30 and re-linking should show that up.
> If I understood the manual of libtool, see [1], correct we should set the
> version as follows:
>
> m4_define(libpcre_version, [1:0:1])
>
> With that setting the library version will be libpcre.so.0.2.0
I don't know much about these settings. The value
> m4_define(libpcre_version, [1:0:0])
was suggested by a PCRE user after the first testing code for 8.30 was
put out, initially without any change to libpcre_version (because I
forgot about this stuff).
> http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Which says:
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.
... which is what has been done (4 and 6).
I have to confess that in the past, I haven't been good at following the
earlier rule:
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’).
I have made a note to do this in future.
Philip
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
