Re: [Gimp-print-devel] shlib versions as intended?

[Greg T. <gd...@le...>]

Robert Krawitz <rl...@al...> writes:

1> On Thu, 10 Oct 2019 14:29:16 -0400, Greg Troxel wrote:
>> I am (belatedly) updating pkgsrc from 5.2.14 to 5.3.3.  I would expect
>> there to be at most one ABI break in there, from 5.2.x to 5.3.x.  I
>> compared the 5.2.14 shlib numbers to 5.3.3, and libgutenprint seems to
>> go from 2.8.0 to 9.4.0.  libgutenprintui2 goes from 1.0.0 to 2.4.0,
>> which is still surprising, as it's one ABI break and 4 ABI addiitions.
>>
>> 5.2.14:
>>   -rwxr-xr-x  1 root  wheel  2534224 Sep 11 01:27 /usr/pkg/lib/libgutenprint.so.2.8.0
>>   -rwxr-xr-x  1 root  wheel   272480 Sep 11 01:27 /usr/pkg/lib/libgutenprintui2.so.1.0.0
>>
>> 5.3.3:
>>   -rwxr-xr-x  1 gdt  users  2672264 Oct 10 14:11 work/.destdir/usr/pkg/lib/libgutenprint.so.9.4.0
>>   -rwxr-xr-x  1 gdt  users   272016 Oct 10 14:11 work/.destdir/usr/pkg/lib/libgutenprintui2.so.2.4.0
>>
>> Perhaps there is some local issue, and perhaps I am confused and/or
>> missing something.  (I tried to find where these are set in the
>> sources, but didn't.)
>
> This all is set by configure.ac.  I *thought* I did it correctly, but
> it's possible I didn't.

I am reading diffs.  This really makes my head hurt and I am someone who
more or less understands this.

A few things (which if you don't want to deal with, I totally understand!):

0) This has been in the all the 5.3.x releases, so we are where we are.

1) There is no tag in git for 5.2.15.  I used -pre1 instead.

2) In configure.ac, there is talk of an error in preparing 5.2.8 and
moving from shlib major 2 to shlib major 4.   But 5.2.15 has
  pushdef([GUTENPRINT_CURRENT_INTERFACE], [10])
  pushdef([GUTENPRINT_BINARY_AGE],        [8])

which is the 2.8 that I'm seeing in build 5.12.15.   That seems good

3) There is MICRO_VERSION in configure.ac for the package version, but I
don't see any micro version for the lib.  I see later you are choosing
not to use it.  That's fine, but the MICRO_VERSION doc guidance to
increment it for lib changes is off base; it represents package
versions.

4) I think the rules as expressed in configure.ac for changing vars due
to incompatible changes are wrong.   It would have been far more helpful
of libtool to have people bump the major and set minor to 0 when there
is an incompatible change, as this is easier to understand.  But this is
the key formula:

  dnl The .soname version is (GCI - GBA).GBA

which means that "GCI++; GBA++" results in no change to MAJOR and
MINOR++.

So, when we want to bump MAJOR, we want the new GCI-GBA to be the old
GCI-GBA + 1.

configure.ac says:

  dnl 3. if interfaces have been deleted or changed *incompatibly*, set
  dnl      GCI = GBA + 1;
  dnl      GBA = 0;

and I think that should be

  dnl      GCI = (GCI-GBA) + 1;

which is pretty counterintuitive.  But the libtool docs say

  GGI = GCI + 1
  GBA = 0

as I read them at

  https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

and that will result in a change from 2.8.0 to 11.0.0, which does not
seem sensible, so I suspect I am confused on some point here.

5) Looking at this diff

  git diff -r gutenprint-5_2_15-pre1 -r gutenprint-5_3_0 configure.ac

and semantically separating out unidiff

 pushdef([GUTENPRINT_NAME],              [gutenprint])
 pushdef([GUTENPRINT_MAJOR_VERSION],     [5])
-pushdef([GUTENPRINT_MINOR_VERSION],     [2])
-pushdef([GUTENPRINT_MICRO_VERSION],     [15])
-pushdef([GUTENPRINT_EXTRA_VERSION],     [-pre1])
+pushdef([GUTENPRINT_MINOR_VERSION],     [3])
+pushdef([GUTENPRINT_MICRO_VERSION],     [0])
+pushdef([GUTENPRINT_EXTRA_VERSION],     [])

-pushdef([GUTENPRINT_CURRENT_INTERFACE], [10])
-pushdef([GUTENPRINT_BINARY_AGE],        [8])
+pushdef([GUTENPRINT_CURRENT_INTERFACE], [9])
+pushdef([GUTENPRINT_BINARY_AGE],        [0])

-pushdef([GUTENPRINTUI2_CURRENT_INTERFACE], [1])
+pushdef([GUTENPRINTUI2_CURRENT_INTERFACE], [2])
 pushdef([GUTENPRINTUI2_BINARY_AGE],        [0])

It looks like the rule as documented was followed for libgutenprint,
resulting in a change from 2.8 to 9.0.  Assuming the ui2 lib had an ABI
break, the rule wasn't followed, but this case shows how the rule
doesn't make sense, as GCI=1/GBA=0 is stable under the rule.


What I would do is put in comments about the desired major and minor and
set:

  GBA = minor
  GCI = major + GBA

basically backing out libtool's logic, and verify that the shlib numbers
are as expected in the builds.


My dim impression is that this GCI/GBA scheme is actually helpful for
some systems that aren't ELF, even though for ELF/a.out it is majorly confusing.