From: Mark Levedahl <mlevedahl@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>,
"Torsten Bögershausen" <tboegi@web.de>,
"Stephen & Linda Smith" <ischis2@cox.net>,
"Jason Pyeron" <jpyeron@pdinc.us>,
git@vger.kernel.org, "Eric Blake" <eblake@redhat.com>
Subject: Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Date: Sun, 06 Jan 2013 17:16:34 -0500 [thread overview]
Message-ID: <50E9F7C2.1000603@gmail.com> (raw)
In-Reply-To: <7vfw2enl2l.fsf@alter.siamese.dyndns.org>
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?
It's perhaps worth noting how we got into this mess. The problems have
their root in
adbc0b6b6e57c11ca49779d01f549260a920a97d
Cygwin's entire goal is a completely POSIX compliant environment running
under Windows. The above commit circumvents some of Cygwin's API
regarding stat/fstat to make things perhaps a bit faster, and definitely
not POSIX compliant (The commit message is wrong, the commit definitely
breaks POSIX compliance). That code is also what will not compile on
different w32api versions. It is curious: the Cygwin mailing list has
been absolutely silent since the w32api change was introduced last
summer, this is the only piece of code I am aware of that was broken by
the new headers, and of course the purpose of this code is to circumvent
the Cygwin API (and by extension, Cygwin project goals).
So, perhaps a better path forward is to disable / remove the above code
by default. (Those wanting a native Win32 git should just use the native
Win32 git).
Mark
next prev parent reply other threads:[~2013-01-06 22:16 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
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 [this message]
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=50E9F7C2.1000603@gmail.com \
--to=mlevedahl@gmail.com \
--cc=eblake@redhat.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ischis2@cox.net \
--cc=jpyeron@pdinc.us \
--cc=jrnieder@gmail.com \
--cc=tboegi@web.de \
/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).