Dear Tom Callaway, Firstly, let me apologise that such an enormous amount of time has passed since you sent the email below to thempirt...@gmail.com. Unfortunately, the person who had been monitoring that email address passed away. Fortunately, he hadn't changed the password. But we only now thought to recover emails from that account!
Thank you for the detailed explanation of the library versioning, which I admit I did not previously understand. I think the reason this got screwed up is because we thought the numbers were in a different order than they really are. I will create a ticket to make sure we get the versioning correct for the upcoming 2.7.0 release of MPIR. But older versions of MPIR are simply not worth updating in my opinion. Once the 2.6.x series finishes we move on to 2.7.0 and do not maintain the old series any more, and so on. Essentially, we expect people to remain up-to-date with the latest release. The reason for this is that we simply don't have the developers to maintain old versions of the library. On the other hand, we should certainly ensure that 2.7.0 has the correct versioning with respect to *all* previous releases of MPIR. We are hoping to have 2.7.0 out at the end of this month. I hope this will solve the problem for you, albeit belatedly. Sorry again for the long delay! Best Regards, Bill. On 4 February 2014 21:39, MPIR Team <thempirt...@googlemail.com> wrote: > > > ---------- Forwarded message ---------- > From: Tom Callaway <tcall...@redhat.com> > Date: 19 August 2012 18:35 > Subject: libtool versioning incorrect > To: thempirt...@gmail.com > Cc: Mark Chappell <trem...@fedoraproject.org> > > > Hello MPIR team, > > I was in the process of updating Fedora's MPIR from 1.3.1 to 2.5.1, and > I noticed that the shared library versioning goes _backwards_, which > should never happen. > > I think your libtool versioning is incorrect. Specifically, you never > should have incremented AGE without also incrementing CURRENT. I quote > from Makefile.am: > > # 1. No interfaces changed, only implementations (good): Increment > REVISION. > # > # 2. Interfaces added, none removed (good): Increment CURRENT, > increment > # AGE, set REVISION to 0. > # > # 3. Interfaces removed (BAD, breaks upward compatibility): Increment > # CURRENT, set AGE and REVISION to 0. > > In case 1, AGE is left as is. In case 2, AGE and CURRENT are > incremented. In case 3, AGE is reset to 0. > > Thus, the only valid situation for incrementing AGE is when CURRENT is > also incremented. The reason for this is because when libtool calculates > shared library versioning, it _subtracts_ AGE from CURRENT for the major > value. The full formula is this: > > libFOO.($CURRENT-$AGE).$AGE.$REVISION > > So, when we look at mpir 1.3.1, we have : > > LIBGMP_LT_CURRENT = 8 > LIBGMP_LT_REVISION = 1 > LIBGMP_LT_AGE = 0 > > LIBGMPXX_LT_CURRENT = 4 > LIBGMPXX_LT_REVISION = 6 > LIBGMPXX_LT_AGE = 1 > > This results in versioned shared libraries as follows: > > /usr/lib/libmpir.so.8.0.1 > /usr/lib/libmpirxx.so.3.1.6 > > When we look at the Makefile.am history (documented in comments) of > changes to MPIR's CURRENT, REVISION, and AGE fields, we see two cases > where AGE was incremented without also incrementing CURRENT. I have > highlighted those times with an * > > # 1.3.1 8:1:0 4:6:1 0:0:0 > # 2.0.0 9:2:0 4:7:1 > # 2.1.0 10;0:1 4:8:1 > * # 2.1.1 10:1:2 4:9:2 > # 2.1.2 10.2.2 4.10.2 > # 2.1.3 10.3.2 4.11.2 > # 2.1.4 10.4.2 4.12.2 > # 2.2.0 10.5.2 4.13.2 > * # 2.2.1 10.6.3 4.14.3 > # 2.3.0 10.7.3 4.15.3 > # 2.3.1 10.8.3 4.16.3 > # 2.4.0 11.0.4 4.17.3 > # 2.5.0 11.1.4 4.18.3 > # 2.5.1 11.2.4 4.19.3 > > Thus, at 2.5.1, we end up with: > > LIBGMP_LT_CURRENT = 11 > LIBGMP_LT_REVISION = 2 > LIBGMP_LT_AGE = 4 > > LIBGMPXX_LT_CURRENT = 4 > LIBGMPXX_LT_REVISION = 19 > LIBGMPXX_LT_AGE = 3 > > Which results in versioned shared libraries as follows: > > /usr/lib/libmpir.so.7.4.2 > /usr/lib/libmpirxx.so.1.3.19 > > Now, I'm not sure what you were trying to do at those points, but you > were not doing it right. :/ Versioned shared libraries should increment > the major version for ABI changes that are not backwards compatible, > that's the logic behind the libtool brain damage. Assuming that the > times which AGE was incremented should have also incremented CURRENT, > 2.5.1 should be: > > # 2.5.1 12.2.4 6.19.3 > > This would result in versioned shared libraries as follows: > > /usr/lib/libmpir.so.8.4.2 > /usr/lib/libmpirxx.so.3.3.19 > > These are not less than MPIR's 1.3.1. In fact, they are indicating ABI > compatibility between MPIR 2.5.1 and 1.3.1 (libmpir.so.8 && > libmpirxx.so.3 in both releases). If this is accurate, then releasing a > MPIR 2.5.2 at: > > # 2.5.2 12.2.4 6.19.3 > > Would resolve this issue properly (yes, it would require all dependent > packages to be rebuilt, but it is better to fix this problem now than to > run into the confusion later when the shared library versioning catches > back up to MPIR 1.3.3). > > Alternately, if MPIR 2.5.1 is _NOT_ ABI compatible with MPIR 1.3.1, then > I suggest that you release a 2.5.2 with the CURRENT, AGE, and RELEASE > set as follows: > > # 2.5.2 13.2.4 7.19.3 > > This would result in versioned shared libraries as follows: > > /usr/lib/libmpir.so.9.4.2 > /usr/lib/libmpirxx.so.4.3.19 > > These libraries have MAJOR versions greater than MPIR 1.3.1 (and the > broken 2.5.1). Then you can just follow the libtool versioning rules > from that point forward and hopefully never have this problem again. > > ***** > > I hope this email makes sense. Please advise me on which path you plan > to take, and when I can expect a MPIR release with this issue resolved. > If there is not one in the near term, I can apply the preferred fix to > Fedora's MPIR package to avoid unnecessary shared versioning bouncing, > however, to ensure consistency between distributions, pushing out a > quick new release to resolve this issue is preferable. > > Thanks in advance, > > Tom Callaway > Fedora Engineering Manager, Red Hat > > == > Fedora Project > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mpir-devel+unsubscr...@googlegroups.com. > To post to this group, send email to mpir-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/mpir-devel. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
