From: "Jason Pyeron" <jpyeron@pdinc.us>
To: <git@vger.kernel.org>
Subject: RE: Version 1.8.1 does not compile on Cygwin 1.7.14
Date: Sun, 6 Jan 2013 16:33:58 -0500 [thread overview]
Message-ID: <D527CF72B81E4F70B390334EC04EA0E8@black> (raw)
In-Reply-To: <50E9E822.4020709@gmail.com>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Mark Levedahl
> Sent: Sunday, January 06, 2013 16:10
> To: Junio C Hamano
> Cc: Jonathan Nieder; Torsten Bögershausen; Stephen & Linda
> Smith; Jason Pyeron; git@vger.kernel.org; Eric Blake
> Subject: Re: Version 1.8.1 does not compile on Cygwin 1.7.14
>
> On 01/06/2013 02:54 PM, Junio C Hamano wrote:
> > Jonathan Nieder <jrnieder@gmail.com> writes:
> >
> >> Mark Levedahl wrote:
> >>
> >>>
> However,
> >>> the newer win32api is provided only for the current
> cygwin release
> >>> series, which can be reliably identified by having dll version
> >>> 1.7.x, while the older frozen releases (dll versions 1.6.x from
> >>> redhat, 1.5.x open source) still have the older api as no
> updates are being made for the legacy version(s).
> >> Ah. That makes sense, thanks.
> >>
> >> (For the future, if we wanted to diagnose an out-of-date
> win32api and
> >> print a helpful message, I guess cygcheck would be the command to
> >> use.)
> > Hmph, so we might see somebody who cares about Cygwin to
> come up with
> > a solution based on cygcheck (not on uname) to update this part,
> > perhaps on top of Peff's "split default settings based on
> uname into
> > separate file" patch?
> >
> > If I understood what Mark and Torsten wrote correctly, you
> will have
> > the new win32api if you install 1.7.17 (or newer) from
> scratch, but if
> > you are on older 1.7.x then you can update the win32api part as a
> > package update (as opposed to the whole-system upgrade). A
> test based
> > on "uname -r" cannot notice that an older 1.7.x (say 1.7.14)
> > installation has a newer win32api because the user updated
> it from the
> > package (hence the user should not define CYGWIN_V15_WIN32API).
> >
> > Am I on the same page as you guys, or am I still behind?
> >
> > In the meantime, perhaps we would need something like this?
> >
> >
> > diff --git a/Makefile b/Makefile
> > index 8e225ca..b45b06d 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -281,6 +281,9 @@ all::
> > #
> > # Define NO_REGEX if you have no or inferior regex
> support in your C library.
> > #
> > +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api
> dll older
> > +than # 1.7.x (this typically is true on Cygwin older than 1.7.17) #
> > # Define HAVE_DEV_TTY if your system can open /dev/tty to
> interact with the
> > # user.
> > #
> >
> Looking at a current setup.ini, the obsolete win32 api is a
> single package "w32api" with last version 3.17-2, and is now
> replaced by the new win32 api is in two packages,
> "w32api-headers" + "w32api-runtime", both at version
> 3.0b_svn5496-1. If setup.exe updated an older installation of
> w32api, the old package is not deleted, but replaced by a
> special "empty" package with (as of today) version 9999-1.
> Note that all of this could change at any time. Also, note
> that the new w32api packages have version numbers that are
> lower than the older obsoleted version.
I would not rely on that information as it is not designed to convey the
information the git build needs.
>
> Running "cygcheck -c w32api w32api-headers w32api-runtime" on
> one machine gives
>
> Cygwin Package Information
> Package Version Status
> w32api 9999-1 OK
> w32api-headers 3.0b_svn5496-1 OK
> w32api-runtime 3.0b_svn5496-1 OK
>
> So now, what do folks propose checking for?
> a) w32api is installed? Nope - the package is not "removed",
> it was updated to a special empty version to delete its
> former contents, but a new fresh installation won't have this.
> b) w32api-headers is installed? Nope - what happens on the
> next repackaging?
> c) w32api version is 9999-1? Maybe, but that number could change.
> etc.
This is what is typically done in a configure script by test compiling.
>
> There is no documented, reliable, future-proof, method of
> determining the installed w32api version on Cygwin. There are
> many things that can be done that will work frequently,
> except when they won't. I really think the only sane thing is
> to follow the guidance of the Cygwin
> developers: the only supported configuration is that which
> the current setup.exe produces, and in the case of problems,
> if the installation is not up to date then updating is the
> first required action.
>
> So, in the makefile, you might add:
>
> +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x
> but are not
> +# using the current w32api packages. But, the recommended
> approach is
> +to # update your installation if compilation errors occur.
> +#
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
next prev parent reply other threads:[~2013-01-06 21:34 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-06 2:04 Version 1.8.1 does not compile on Cygwin 1.7.14 Stephen & Linda Smith
2013-01-06 3:37 ` Jason Pyeron
2013-01-06 4:22 ` Jason Pyeron
2013-01-06 6:20 ` Stephen & Linda Smith
2013-01-06 6:29 ` Jason Pyeron
2013-01-06 7:23 ` Torsten Bögershausen
2013-01-06 9:32 ` Jonathan Nieder
2013-01-06 9:42 ` Torsten Bögershausen
2013-01-06 9:57 ` Jonathan Nieder
2013-01-06 11:48 ` Mark Levedahl
2013-01-06 12:09 ` Jonathan Nieder
2013-01-06 14:09 ` Stephen & Linda Smith
2013-01-06 19:54 ` Junio C Hamano
2013-01-06 20:51 ` Torsten Bögershausen
2013-01-06 21:34 ` Mark Levedahl
2013-01-06 21:09 ` Mark Levedahl
2013-01-06 21:33 ` Jason Pyeron [this message]
2013-01-06 21:35 ` Junio C Hamano
2013-01-06 21:46 ` Jason Pyeron
2013-01-06 22:00 ` Mark Levedahl
2013-01-06 22:16 ` Mark Levedahl
2013-01-07 5:37 ` Jason Pyeron
2013-01-07 7:29 ` Junio C Hamano
2013-01-07 9:10 ` Pyeron, Jason J CTR (US)
2013-01-08 3:12 ` Mark Levedahl
2013-01-11 20:08 ` Alex Riesen
2013-01-11 20:17 ` Alex Riesen
2013-01-13 18:58 ` Mark Levedahl
2013-01-15 18:47 ` Ramsay Jones
2013-01-20 10:10 ` Jonathan Nieder
2013-01-20 10:48 ` Torsten Bögershausen
2013-01-20 11:06 ` Jonathan Nieder
2013-01-21 5:20 ` [msysGit] " Torsten Bögershausen
2013-01-22 18:38 ` Ramsay Jones
2013-01-22 18:31 ` Ramsay Jones
2013-01-25 23:58 ` Mark Levedahl
2013-01-26 0:11 ` Junio C Hamano
2013-01-26 0:34 ` Eric Blake
2013-01-26 1:03 ` [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS Jonathan Nieder
2013-01-26 14:11 ` Mark Levedahl
2013-01-26 17:21 ` Torsten Bögershausen
2013-01-28 18:29 ` Ramsay Jones
2013-02-25 6:44 ` Junio C Hamano
2013-02-26 4:08 ` Mark Levedahl
2013-02-26 16:40 ` Torsten Bögershausen
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D527CF72B81E4F70B390334EC04EA0E8@black \
--to=jpyeron@pdinc.us \
--cc=git@vger.kernel.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).