From: Charles Wilson <cygwin@cwilson.fastmail.fm>
To: Mailing List: CygWin-Apps <cygwin-apps@cygwin.com>
Subject: Re: gmp-4.2.2-1 and and mpfr- for upload
Date: Tue, 25 Mar 2008 17:10:00 -0000 [thread overview]
Message-ID: <47E931E7.5070800@cwilson.fastmail.fm> (raw)
In-Reply-To: <029601c88e7b$54aa55f0$2708a8c0@CAM.ARTIMI.COM>
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
next prev parent reply other threads:[~2008-03-25 17:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-24 3:43 David Billinghurst
2008-03-25 13:23 ` Dave Korn
2008-03-25 17:10 ` Charles Wilson [this message]
2008-03-26 12:18 ` David Billinghurst
2008-03-31 11:30 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E931E7.5070800@cwilson.fastmail.fm \
--to=cygwin@cwilson.fastmail.fm \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).