Charles Wilson wrote:
Dave Korn wrote:
David Billinghurst wrote on 24 March 2008 03:43:
The version number of libgmpxx was bumped in the upstream files to
correct the shared library numbers. I reverted this change in the
cygwin build as the cygwin shared library is backwards compatible with
gmp-4.2.1 - the 4.2.1 testsuite passes with the new cyggmpxx-3.dll.
On the face of it, that sounds like a worryingly dubious idea.
Not necessarily. It is often the case that the version number of
cygwin's library ports (I don't want to say cygwin DLL because that
could be misconstrued) do not exactly follow the upstream versioning.
Most of the time, it's because there have been cygwin-specific changes
that have forced our version number ahead of the upstream progression.
Take ncurses, for instance: upstream so's are at version 5.0 or so, but
our DLL number is 8.
In rare cases, we might fall behind the upstream numbers -- imagine if
an ABI change occurred, but only #ifdef SOLARIS -- there'd be no reason
(other than a desire for consistency) to bump the cygwin port's DLL number.
However, in the case of gmp, it is probably necessary to understand WHY
the upstream maintainers bumped the DLL number. Did they make a
back-wards incompatible change sometime early in the -3 sequence, but
neglected to update the number until now? Or is the new version number
merely cosmetic?
correct the shared library numbers just doesn't provide enough
information.
--
Chuck
The new 4.2.2-1 cyggmpxx3.dll is AFAICT binary compatible with the
current 4.2.1-1 release. The changes are quite small and I ran the
4.2.1-1 testsuite with the 4.2.2-1 DLL without problem.
I don't have strong feelings about this change, but we will have to bump
the C++ library version when we move to gcc-4. I thought it excessive
to change it now for no real reason.
According to http://gmplib.org/ - Additional issues with GMP 4.2: The
solib numbers for the shared version of libgmp and libgmpxx are very
wrong, making them appear older than version 4.1.4.
David
