Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/25/2013 05:11 PM, Junio C Hamano wrote: > Mark Levedahl writes: > >> Cygwin and Windows should be treated as completely separate platforms: >> if __CYGWIN__ is defined, do one thing, if not, go ahead and check >> WIN32, but the WIN32 macro should never be tested once we know the >> platform is CYGWIN - these really are different platforms (if you are >> unsure of this, consider that Cygwin includes a cross-compiler to >> target native Win32 as the Cygwin maintainers recognized the platforms >> are different). > > Not disagreeing with your conclusion (they should be treated as > different), why does it define WIN32 in the first place? > > Perhaps we would want > > #ifdef __CYGWIN__ > #undef WIN32 > #endif Wouldn't work. Cygwin gcc does NOT define WIN32; rather, the inclusion of a Windows system header (generally discouraged, but sometimes a necessary evil) might cause WIN32 to be defined for all subsequent headers. Which is why other projects, like gnulib, have # if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__ all over the place. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Mark Levedahl writes: > Cygwin and Windows should be treated as completely separate platforms: > if __CYGWIN__ is defined, do one thing, if not, go ahead and check > WIN32, but the WIN32 macro should never be tested once we know the > platform is CYGWIN - these really are different platforms (if you are > unsure of this, consider that Cygwin includes a cross-compiler to > target native Win32 as the Cygwin maintainers recognized the platforms > are different). Not disagreeing with your conclusion (they should be treated as different), why does it define WIN32 in the first place? Perhaps we would want #ifdef __CYGWIN__ #undef WIN32 #endif very early in some include file before nothing else is included? Just being curious. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/22/2013 01:31 PM, Ramsay Jones wrote: include order. ;-) As I have mentioned here before, the claim that "WIN32 is not defined on cygwin" is simply nonsense - it depends on if/when certain header files are included. For example, *as soon as* you include (and, I suspect, many other win32 headers) then "defined(WIN32)" is true. Note that commit 380a4d92 ("Update cygwin.c for new mingw-64 win32 api headers", 11-11-2012) swaps the include order for the win32.h and git-compat-util.h header files. [I don't know the details, Mark didn't elaborate, but it is clearly an include order problem on cygwin 1.7.x :-D ] This causes compilation errors on cygwin 1.5.x, exactly because win32.h includes , which defines WIN32, which then leads to git-compat-util.h including . #if defined(WIN32) && defined(__CYGWIN__) # undef WIN32 #endif Cygwin and Windows should be treated as completely separate platforms: if __CYGWIN__ is defined, do one thing, if not, go ahead and check WIN32, but the WIN32 macro should never be tested once we know the platform is CYGWIN - these really are different platforms (if you are unsure of this, consider that Cygwin includes a cross-compiler to target native Win32 as the Cygwin maintainers recognized the platforms are different). Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Torsten Bögershausen wrote: > On 20.01.13 12:06, Jonathan Nieder wrote: >> Torsten Bögershausen wrote: >> >>> I wonder, if if we can go one step further: >>> >>> Replace >>> #ifdef WIN32 /* Both MinGW and MSVC */ >> [...] >>> with >>> #if defined(_MSC_VER) >> >> I thought Git for Windows was built using mingw, which doesn't define >> _MSC_VER? >> >> Puzzled, >> Jonathan >> > Yes, > After removing these lines in the git-compat-util.h of msysgit > v1.8.1 it still compiled. > So I start to speculate if the comment is still valid for mingw, > or if that was true in the old days and not now any more. > > More investigation is needed, sorry for confusion. Yes, I compiled the last patch on MinGW before I sent it to the list. I didn't bother with MSVC, since that build is already broken. I have a patch which fixed the MSVC build, but it already needs to be updated, since current master fails to build on MSVC. ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Jonathan Nieder wrote: > Ramsay Jones wrote: > >> --- a/git-compat-util.h >> +++ b/git-compat-util.h >> @@ -85,12 +85,6 @@ >> #define _NETBSD_SOURCE 1 >> #define _SGI_SOURCE 1 >> >> -#ifdef WIN32 /* Both MinGW and MSVC */ >> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ >> -#include >> -#include >> -#endif > > So, do I understand correctly that the above conditional should be > something like > > #if defined(WIN32) && !defined(__CYGWIN__) > > to allow dropping the CYGWIN_V15_WIN32API setting? Yes, replacing the git-compat-util.h hunk above with: diff --git a/git-compat-util.h b/git-compat-util.h index e5a4b74..a38ae8d 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -85,7 +85,7 @@ #define _NETBSD_SOURCE 1 #define _SGI_SOURCE 1 -#ifdef WIN32 /* Both MinGW and MSVC */ +#if defined(WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */ #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ #include #include will also compile on cygwin 1.5.x > "defined(WIN32)" is used throughout git to mean "win32 and not > cygwin", so if I understand correctly we would either need to do Hmm ... I remember being *very* nervous of commit 435bdf8c ("Make usage of windows.h lean and mean", 16-09-2009) exactly because it makes the code (on cygwin) much more fragile with respect to header include order. ;-) As I have mentioned here before, the claim that "WIN32 is not defined on cygwin" is simply nonsense - it depends on if/when certain header files are included. For example, *as soon as* you include (and, I suspect, many other win32 headers) then "defined(WIN32)" is true. Note that commit 380a4d92 ("Update cygwin.c for new mingw-64 win32 api headers", 11-11-2012) swaps the include order for the win32.h and git-compat-util.h header files. [I don't know the details, Mark didn't elaborate, but it is clearly an include order problem on cygwin 1.7.x :-D ] This causes compilation errors on cygwin 1.5.x, exactly because win32.h includes , which defines WIN32, which then leads to git-compat-util.h including . > #if defined(WIN32) && defined(__CYGWIN__) > # undef WIN32 > #endif Hmm, except when you want it defined on cygwin, of course ... ;-) > Thanks for investigating. No problem. I've included the updated patch below, just for completeness. HTH ATB, Ramsay Jones -- >8 -- Subject: [PATCH] cygwin: Remove the CYGWIN_V15_WIN32API config Signed-off-by: Ramsay Jones --- Makefile | 7 --- compat/cygwin.c | 5 - config.mak.uname | 1 - git-compat-util.h | 2 +- 4 files changed, 1 insertion(+), 14 deletions(-) diff --git a/Makefile b/Makefile index 1b30d7b..1c84f68 100644 --- a/Makefile +++ b/Makefile @@ -281,10 +281,6 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # -# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not -# using the current w32api packages. The recommended approach, however, -# is to update your installation if compilation errors occur. -# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # @@ -1402,9 +1398,6 @@ ifdef NO_REGEX COMPAT_CFLAGS += -Icompat/regex COMPAT_OBJS += compat/regex/regex.o endif -ifdef CYGWIN_V15_WIN32API - COMPAT_CFLAGS += -DCYGWIN_V15_WIN32API -endif ifdef USE_NED_ALLOCATOR COMPAT_CFLAGS += -Icompat/nedmalloc diff --git a/compat/cygwin.c b/compat/cygwin.c index 5428858..0a9aa6d 100644 --- a/compat/cygwin.c +++ b/compat/cygwin.c @@ -1,13 +1,8 @@ #define WIN32_LEAN_AND_MEAN -#ifdef CYGWIN_V15_WIN32API -#include "../git-compat-util.h" -#include "win32.h" -#else #include #include #include "win32.h" #include "../git-compat-util.h" -#endif #include "../cache.h" /* to read configuration */ static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts) diff --git a/config.mak.uname b/config.mak.uname index bea34f0..5e493c9 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -158,7 +158,6 @@ ifeq ($(uname_O),Cygwin) NO_SYMLINK_HEAD = YesPlease NO_IPV6 = YesPlease OLD_ICONV = UnfortunatelyYes - CYGWIN_V15_WIN32API = YesPlease endif NO_THREAD_SAFE_PREAD = YesPlease NEEDS_LIBICONV = YesPlease diff --git a/git-compat-util.h b/git-compat-util.h index e5a4b74..a38ae8d 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -85,7 +85,7 @@ #define _NETBSD_SOURCE 1 #define _SGI_SOURCE 1 -#ifdef WIN32 /* Both MinGW and MSVC */ +#if defined(WIN32) && !defined(__CYGWIN__) /* Both MinGW and MSVC */ #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ #include #include -- 1.8.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 20.01.13 12:06, Jonathan Nieder wrote: > Torsten Bögershausen wrote: > >> I wonder, if if we can go one step further: >> >> Replace >> #ifdef WIN32 /* Both MinGW and MSVC */ > [...] >> with >> #if defined(_MSC_VER) > > I thought Git for Windows was built using mingw, which doesn't define > _MSC_VER? > > Puzzled, > Jonathan > Yes, After removing these lines in the git-compat-util.h of msysgit v1.8.1 it still compiled. So I start to speculate if the comment is still valid for mingw, or if that was true in the old days and not now any more. More investigation is needed, sorry for confusion. /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Torsten Bögershausen wrote: > I wonder, if if we can go one step further: > > Replace > #ifdef WIN32 /* Both MinGW and MSVC */ [...] > with > #if defined(_MSC_VER) I thought Git for Windows was built using mingw, which doesn't define _MSC_VER? Puzzled, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 20.01.13 11:10, Jonathan Nieder wrote: > Ramsay Jones wrote: > >> --- a/git-compat-util.h >> +++ b/git-compat-util.h >> @@ -85,12 +85,6 @@ >> #define _NETBSD_SOURCE 1 >> #define _SGI_SOURCE 1 >> >> -#ifdef WIN32 /* Both MinGW and MSVC */ >> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ >> -#include >> -#include >> -#endif > > So, do I understand correctly that the above conditional should be > something like > > #if defined(WIN32) && !defined(__CYGWIN__) > > to allow dropping the CYGWIN_V15_WIN32API setting? > > "defined(WIN32)" is used throughout git to mean "win32 and not > cygwin", so if I understand correctly we would either need to do > > #if defined(WIN32) && defined(__CYGWIN__) > # undef WIN32 > #endif > > or define a new GIT_WIN32 (name is just a placeholder) macro to use > consistently in its stead. > > Thanks for investigating. > Jonathan I wonder, if if we can go one step further: Replace #ifdef WIN32 /* Both MinGW and MSVC */ #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ #include #include #endif with #if defined(_MSC_VER) #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ #include #include #endif Any thougths from msysGit ? /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Ramsay Jones wrote: > --- a/git-compat-util.h > +++ b/git-compat-util.h > @@ -85,12 +85,6 @@ > #define _NETBSD_SOURCE 1 > #define _SGI_SOURCE 1 > > -#ifdef WIN32 /* Both MinGW and MSVC */ > -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ > -#include > -#include > -#endif So, do I understand correctly that the above conditional should be something like #if defined(WIN32) && !defined(__CYGWIN__) to allow dropping the CYGWIN_V15_WIN32API setting? "defined(WIN32)" is used throughout git to mean "win32 and not cygwin", so if I understand correctly we would either need to do #if defined(WIN32) && defined(__CYGWIN__) # undef WIN32 #endif or define a new GIT_WIN32 (name is just a placeholder) macro to use consistently in its stead. Thanks for investigating. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Mark Levedahl wrote: > On 01/11/2013 03:17 PM, Alex Riesen wrote: >> On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen wrote: >>> This short discussion on GitHub (file git-compat-util.h) might be relevant: >>> >>> https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194 >>> >>> The change suggested there (to remove an inclusion of windows.h in >>> git-compat-util.h) might simplify the solution a little. Might even >>> remove the need for auto-configuration in Makefile (worked for me). >> Just to be clear, the change is this: >> >> diff --git a/git-compat-util.h b/git-compat-util.h >> index 4a1979f..780a919 100644 >> --- a/git-compat-util.h >> +++ b/git-compat-util.h >> @@ -85,12 +85,6 @@ >> #define _NETBSD_SOURCE 1 >> #define _SGI_SOURCE 1 >> >> -#ifdef WIN32 /* Both MinGW and MSVC */ >> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ >> -#include >> -#include >> -#endif >> - >> #include >> #include >> #include >> > That change alone seems fine, no apparent change building on current > cygwin. However, with that change the build still fails if > CYGWIN_V15_WIN32API is defined, so unless someone can show the > compilation works on cygwin1.5 WITHOUT defining CYGWIN_V15_WIN32API this > change does not help. I do not have an older installation available, so > cannot test. Frankly, assuming you can compile with that macro defined, > I would suggest leaving well enough alone - an unsupported configuration > is unsupported :^) I haven't been following this thread too closely, so I may have misunderstood what you would like to test but, since I use cygwin 1.5, I tried the patch given below. I only had time to compile test this patch (ie I have *not* run any of the tests - it takes over 3 hours for me), but it seems to work to that extent. (I also tried a few simple commands: status, diff, branch; seems to work OK.) If you would like me to test something else, just let me know. HTH ATB, Ramsay Jones -- >8 -- diff --git a/Makefile b/Makefile index 1b30d7b..1c84f68 100644 --- a/Makefile +++ b/Makefile @@ -281,10 +281,6 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # -# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not -# using the current w32api packages. The recommended approach, however, -# is to update your installation if compilation errors occur. -# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # @@ -1402,9 +1398,6 @@ ifdef NO_REGEX COMPAT_CFLAGS += -Icompat/regex COMPAT_OBJS += compat/regex/regex.o endif -ifdef CYGWIN_V15_WIN32API - COMPAT_CFLAGS += -DCYGWIN_V15_WIN32API -endif ifdef USE_NED_ALLOCATOR COMPAT_CFLAGS += -Icompat/nedmalloc diff --git a/compat/cygwin.c b/compat/cygwin.c index 5428858..0a9aa6d 100644 --- a/compat/cygwin.c +++ b/compat/cygwin.c @@ -1,13 +1,8 @@ #define WIN32_LEAN_AND_MEAN -#ifdef CYGWIN_V15_WIN32API -#include "../git-compat-util.h" -#include "win32.h" -#else #include #include #include "win32.h" #include "../git-compat-util.h" -#endif #include "../cache.h" /* to read configuration */ static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts) diff --git a/config.mak.uname b/config.mak.uname index bea34f0..5e493c9 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -158,7 +158,6 @@ ifeq ($(uname_O),Cygwin) NO_SYMLINK_HEAD = YesPlease NO_IPV6 = YesPlease OLD_ICONV = UnfortunatelyYes - CYGWIN_V15_WIN32API = YesPlease endif NO_THREAD_SAFE_PREAD = YesPlease NEEDS_LIBICONV = YesPlease diff --git a/git-compat-util.h b/git-compat-util.h index e5a4b74..3186e55 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -85,12 +85,6 @@ #define _NETBSD_SOURCE 1 #define _SGI_SOURCE 1 -#ifdef WIN32 /* Both MinGW and MSVC */ -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ -#include -#include -#endif - #include #include #include -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/11/2013 03:17 PM, Alex Riesen wrote: On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen wrote: This short discussion on GitHub (file git-compat-util.h) might be relevant: https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194 The change suggested there (to remove an inclusion of windows.h in git-compat-util.h) might simplify the solution a little. Might even remove the need for auto-configuration in Makefile (worked for me). Just to be clear, the change is this: diff --git a/git-compat-util.h b/git-compat-util.h index 4a1979f..780a919 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -85,12 +85,6 @@ #define _NETBSD_SOURCE 1 #define _SGI_SOURCE 1 -#ifdef WIN32 /* Both MinGW and MSVC */ -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ -#include -#include -#endif - #include #include #include That change alone seems fine, no apparent change building on current cygwin. However, with that change the build still fails if CYGWIN_V15_WIN32API is defined, so unless someone can show the compilation works on cygwin1.5 WITHOUT defining CYGWIN_V15_WIN32API this change does not help. I do not have an older installation available, so cannot test. Frankly, assuming you can compile with that macro defined, I would suggest leaving well enough alone - an unsupported configuration is unsupported :^) Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen wrote: > This short discussion on GitHub (file git-compat-util.h) might be relevant: > > https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194 > > The change suggested there (to remove an inclusion of windows.h in > git-compat-util.h) might simplify the solution a little. Might even > remove the need for auto-configuration in Makefile (worked for me). Just to be clear, the change is this: diff --git a/git-compat-util.h b/git-compat-util.h index 4a1979f..780a919 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -85,12 +85,6 @@ #define _NETBSD_SOURCE 1 #define _SGI_SOURCE 1 -#ifdef WIN32 /* Both MinGW and MSVC */ -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ -#include -#include -#endif - #include #include #include -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
This short discussion on GitHub (file git-compat-util.h) might be relevant: https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194 The change suggested there (to remove an inclusion of windows.h in git-compat-util.h) might simplify the solution a little. Might even remove the need for auto-configuration in Makefile (worked for me). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/07/2013 02:29 AM, Junio C Hamano wrote: I do not have much stake in this personally, but IIRC, the (l)stat workaround was back then found to make Cygwin version from "unusably slow" to "slow but torelable", as our POSIX-y codebase assumes that lstat is fairly efficient, which Cygwin cannot satisify because it has call many win32 calls to collect bits that we do not even look at, in order to give faithful emulation. It does place extra maintenance burden The maintenance burden is the only issue here, and I just wanted to point out the origin. I never enable that run-time option, the small gain in speed cannot compensate the loss of cross-platform operations for my uses. Actually, my git usage is mostly on Linux, but it seems 99% of my maintenance time is on the cygwin side that I almost never use. Sigh. Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: Junio C Hamano > Sent: Monday, January 07, 2013 2:29 AM > > Jason Pyeron writes: > > [administrivia: please never cull CC list when you respond to a > message on this list without a good reason] Apologies, I just have 4 copies of every message and was trying to save other that pain. > > >> 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). > > > > Or a make option... > > It already is a runtime option, isn't it? > > I do not have much stake in this personally, but IIRC, the (l)stat > workaround was back then found to make Cygwin version from "unusably > slow" to "slow but torelable", as our POSIX-y codebase assumes that > lstat is fairly efficient, which Cygwin cannot satisify because it Is there already a set of test cases I can run to validate that this is still true? > has call many win32 calls to collect bits that we do not even look > at, in order to give faithful emulation. It does place extra > maintenance burden (e.g. conditional compilation depending on the > header file the particular version of Cygwin installation the user > has at hand) on us, but as long as it works, the ugly hack is fairly There seems to be only 2 valid use cases here, with regards to cygwin. 1. Do it the normal posix way, and dont hack it up. 2. For speed reasons, merge in native windows/non-posix functions. I would not care about the user's cygwin version because the cygwin supporters won't either. In both cases assume the latest cygwin libraries. If there is a specific user with a use case for an older version of cygwin libraries then we can cross that bridge when (if) we arrive at it. > isolated and I do not see a reason to unconditionally rip it out, > especially if the reasoning behind such move is on "All programs > that run in Cygwin environment has to be POSIX only and must not use > Win32 API directly, even in a controlled way." I presently do not care if it stays or goes. But if someone were to bring this to the cygwin mailing list it would be a headache to deal with the "hacked" way. They would likely be more receptive to increasing the efficiency of the lstat than other approaches. > > It is a completely different matter if the direct win32 calls we > make, bypassing (l)stat emulation, somehow change the internal state > of win32 resources Cygwin controls and violates the invariants > Cygwin API implemenation expects, breaking later calls to it. I > do not know that is the case here, but I doubt it. I agree, it is not going to break anything here. Those libraries are just a way of presenting the Windows API without using Microsoft files and making it easier to wrap the POSIX apis to it. smime.p7s Description: S/MIME cryptographic signature
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
"Jason Pyeron" writes: [administrivia: please never cull CC list when you respond to a message on this list without a good reason] >> 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). > > Or a make option... It already is a runtime option, isn't it? I do not have much stake in this personally, but IIRC, the (l)stat workaround was back then found to make Cygwin version from "unusably slow" to "slow but torelable", as our POSIX-y codebase assumes that lstat is fairly efficient, which Cygwin cannot satisify because it has call many win32 calls to collect bits that we do not even look at, in order to give faithful emulation. It does place extra maintenance burden (e.g. conditional compilation depending on the header file the particular version of Cygwin installation the user has at hand) on us, but as long as it works, the ugly hack is fairly isolated and I do not see a reason to unconditionally rip it out, especially if the reasoning behind such move is on "All programs that run in Cygwin environment has to be POSIX only and must not use Win32 API directly, even in a controlled way." It is a completely different matter if the direct win32 calls we make, bypassing (l)stat emulation, somehow change the internal state of win32 resources Cygwin controls and violates the invariants Cygwin API implemenation expects, breaking later calls to it. I do not know that is the case here, but I doubt it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: Mark Levedahl > Sent: Sunday, January 06, 2013 17:17 > > On 01/06/2013 02:54 PM, Junio C Hamano wrote: > > Jonathan Nieder 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 Ug! > 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 Um, going out on a limb here, but those headers are used internally as "cygwin" apps are most likely to now know about those headers. > 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). Or a make option... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/06/2013 04:35 PM, Junio C Hamano wrote: Thanks; so perhaps you can give me an OK to forge your S-o-b to the following? -- >8 -- From: Mark Levedahl Date: Sun, 6 Jan 2013 11:56:33 -0800 Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API There is no documented, reliable, and future-proof method to determine the installed w32api version on Cygwin. There are many things that can be done that will work frequently, except when they won't. 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. Signed-off-by: Mark Levedahl --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 4d47af5..52e298a 100644 --- a/Makefile +++ b/Makefile @@ -273,6 +273,10 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not +# using the current w32api packages. The recommended approach, however, +# is to update your installation if compilation errors occur. +# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # Absolutely, that is ok by me. Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: Junio C Hamano > Sent: Sunday, January 06, 2013 16:36 > > Thanks; so perhaps you can give me an OK to forge your S-o-b > to the following? I am personally fine with it, because cygwin is used by developers not production systems and I expect my developers to upgrade their environment for security fixes, etc. If I ever had a situation where I am using git, in production, on cygwin, where I could not upgrade I would effort to make a compile test based patch to the make file to accommodate the issue. > > -- >8 -- > From: Mark Levedahl > Date: Sun, 6 Jan 2013 11:56:33 -0800 > Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API > > There is no documented, reliable, and future-proof method to > determine the installed w32api version on Cygwin. There are > many things that can be done that will work frequently, > except when they won't. > > 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. > > Signed-off-by: Mark Levedahl > --- > Makefile | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Makefile b/Makefile > index 4d47af5..52e298a 100644 > --- a/Makefile > +++ b/Makefile > @@ -273,6 +273,10 @@ all:: > # > # Define NO_REGEX if you have no or inferior regex support > in your C library. > # > +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x > but are not > +# using the current w32api packages. The recommended > approach, however, > +# is to update your installation if compilation errors occur. > +# > # Define HAVE_DEV_TTY if your system can open /dev/tty to > interact with the # user. > # > -- > 1.8.1.302.g0f4eaa7 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Thanks; so perhaps you can give me an OK to forge your S-o-b to the following? -- >8 -- From: Mark Levedahl Date: Sun, 6 Jan 2013 11:56:33 -0800 Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API There is no documented, reliable, and future-proof method to determine the installed w32api version on Cygwin. There are many things that can be done that will work frequently, except when they won't. 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. Signed-off-by: Mark Levedahl --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 4d47af5..52e298a 100644 --- a/Makefile +++ b/Makefile @@ -273,6 +273,10 @@ all:: # # Define NO_REGEX if you have no or inferior regex support in your C library. # +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x but are not +# using the current w32api packages. The recommended approach, however, +# is to update your installation if compilation errors occur. +# # Define HAVE_DEV_TTY if your system can open /dev/tty to interact with the # user. # -- 1.8.1.302.g0f4eaa7 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/06/2013 03:51 PM, Torsten Bögershausen wrote: Hm, I haven't understood the connection between the dll (cygwin1.dll ?) which is used in runtime, and the header files which are used when compiling. Are they updated at the same time when updating from 1.7.16 to 1.7.17 ? Until I updated my cygwin 1.7 (following Marks recommendation) this did the trick for me: +ifeq ($(shell grep mingw /usr/include/w32api/winsock2.h />/dev/null 2>/dev/null && echo y),y) + CYGWIN_V15_WIN32API=YesPlease +endif As an alternative, would this be easier to read? +# Define CYGWIN_V15_WIN32API for Cygwin versions up to 1.7.16 The cygwin distribution has a very large number of packages, each with its own unique version number and update rhythm, just as in any linux distro. There is no "cygwin version", just a version for each individual package. So, "Cygwin version 1.7.16" is really nonsensical: there is only cygwin.dll version 1.7.16. What folks are noticing is a coincidence in the time when the cygwin dll package updated and when the old w32api was obsoleted. uname -r reports the cygwin dll version, not the version of any other package. Note that the cygwin api is "stable", meaning a package compiled against the 1.7.1 dll will still run against the current one: updating the cygwin dll does not require other packages to update. The only hard linkage here is that the Cygwin developers are maintaining a legacy cygwin version (v1.5.x) as the newer dll series (v.1.7.x) dropped support for all Windows versions predating (I think) WinXP. So, someone on an old Windows version must use the legacy cygwin version which has not been updated since the first v1.7 dll was released, nor are there any plans by the developers to ever update the v1.5 packages. Cygwin 1.5 lives in a separate distribution repository, with packages frozen in time as of the last updates prior to going to v1.7 (packages compiled against v1.7 will not run on v.1.5). So, encountering a v1.5.x dll is a guarantee of using the older w32api shared with the mingw project, rather than the current one now maintained by the mingw64 project. However, a cygwin with any v1.7.x dll could in theory have either w32api installed, or in theory yet another newer one we don't know about yet. Unless and until the w32api establishes a version number (independent of the Windows API version), we have nothing reliable to use. Therefore, if using the v1.7 series, *update* Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: git-ow...@vger.kernel.org > [mailto:git-ow...@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 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 -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 VersionStatus > w32api -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 -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
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 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 -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. Running "cygcheck -c w32api w32api-headers w32api-runtime" on one machine gives Cygwin Package Information Package VersionStatus w32api -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 -1? Maybe, but that number could change. etc. 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. +# Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 06.01.13 20:54, Junio C Hamano wrote: > Jonathan Nieder 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. > # Hm, I haven't understood the connection between the dll (cygwin1.dll ?) which is used in runtime, and the header files which are used when compiling. Are they updated at the same time when updating from 1.7.16 to 1.7.17 ? Until I updated my cygwin 1.7 (following Marks recommendation) this did the trick for me: +ifeq ($(shell grep mingw /usr/include/w32api/winsock2.h />/dev/null 2>/dev/null && echo y),y) + CYGWIN_V15_WIN32API=YesPlease +endif As an alternative, would this be easier to read? > +# Define CYGWIN_V15_WIN32API for Cygwin versions up to 1.7.16 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Jonathan Nieder 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. # -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On Sunday, January 06, 2013 04:09:17 AM Jonathan Nieder wrote: > 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.) Thank you for the information. I will update my cygwin installation. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
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.) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/06/2013 04:57 AM, Jonathan Nieder wrote: Torsten Bögershausen wrote: The short version: Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5 [...] I don't know if we want to improve the Makefile to enable CYGWIN_V15_WIN32API = YesPlease for cygwin versions 1.7.1 .. 1.7.16 (which are outdated) You are conflating the cygwin dll version with the win32 api version. These are independent packages (just as the kernel and glibc packages are independent on linux) and do not share a version number. 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). Cygwin does not version the win32api in any useful way: the package names changed completely, for instance, and there is no macro defined from the header files to indicate a version number. Also, there is no supported way to now install the older version: the only supported configuration is with the *current* win32api: multiple packages depend by name on the current win32api package, so the installer will insist upon its installation. So the solution is to update the cygwin installation. Really. If you don't believe me, try asking on the cygwin mailing list. They only support the current releases, not obsolete packages, and the older win32api is explicitly obsolete. Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Torsten Bögershausen wrote: > The short version: > Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5 [...] > I don't know if we want to improve the Makefile to enable > CYGWIN_V15_WIN32API = YesPlease > for cygwin versions 1.7.1 .. 1.7.16 (which are outdated) Confusing. Sounds like the condition in 380a4d92 (Update cygwin.c for new mingw-64 win32 api headers, 2012-11-11) was too strict and the Makefile should say something like # Cygwin versions up to 1.7.16 used the same headers # as Cygwin 1.5. ifeq ($(shell expr "$(uname_R)" : '1\.7\.[0-9]$$'),5) CYGWIN_V15_WIN32API = YesPlease endif ifeq ($(shell expr "$(uname_R)" : '1\.7\.1[0-6]$$'),6) CYGWIN_V15_WIN32API = YesPlease endif ifeq ($(shell expr "$(uname_R)" : '1\.[1-6]\.'),4) CYGWIN_V15_WIN32API = YesPlease ... endif Is that right? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 06.01.13 10:32, Jonathan Nieder wrote: > Hi, > > Torsten Bögershausen wrote: >>> Stephen & Linda Smith wrote: > git co 9fca6c && make all ... The make errored out as before > [...] git co 9fca6c^ && make all ... and this compiles to completion CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22 i686 Cygwin > [...] >> You can either upgrade to cygwin 1.17 or higher. >> Or, if that is really not possible (because you are sitting on a production >> machine, >> where no changes are allowed), >> >> You can enable this in Makefile: >> CYGWIN_V15_WIN32API = YesPlease > > What I don't understand is why commit 9fca6c would have had any > effect at all. Since 1.7.14 doesn't match /^1\.[1-6]\./, wouldn't > the setting to avoid including and be > unset both before and after that commit? > > Stephen, what is the content of your config.mak? > > Curious, > Jonathan The short version: Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5 The change in cygwin came in in 1.7.17, (and from that version of cygwin we need commit 9fca6c to compile git) Currently we can not compile git under cygwin 1.7.1 .. 1.7.16 :-( As "everybody" running cygwin 1.7 seems to update to the latest, I don't know if we want to improve the Makefile to enable CYGWIN_V15_WIN32API = YesPlease for cygwin versions 1.7.1 .. 1.7.16 (which are outdated) /Torsten http://git.661346.n2.nabble.com/PATCH-Rename-V15-MINGW-HEADERS-into-CYGWIN-OLD-WINSOCK-HEADERS-td7571449.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
Hi, Torsten Bögershausen wrote: >> Stephen & Linda Smith wrote: >>> git co 9fca6c && make all >>> ... The make errored out as before [...] >>> git co 9fca6c^ && make all >>> ... and this compiles to completion >>> >>> CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22 >>> i686 Cygwin [...] > You can either upgrade to cygwin 1.17 or higher. > Or, if that is really not possible (because you are sitting on a production > machine, > where no changes are allowed), > > You can enable this in Makefile: > CYGWIN_V15_WIN32API = YesPlease What I don't understand is why commit 9fca6c would have had any effect at all. Since 1.7.14 doesn't match /^1\.[1-6]\./, wouldn't the setting to avoid including and be unset both before and after that commit? Stephen, what is the content of your config.mak? Curious, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 06.01.13 07:29, Jason Pyeron wrote: >> -Original Message- >> From: Stephen & Linda Smith >> Sent: Sunday, January 06, 2013 1:21 >> >>> Was it the commit before >>> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it >>> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I >> am doing a >>> cygwin update presently to look at it. >> >> Since the email earlier today, I had blown away the >> directory. I just now >> did the following >> >> git clone https://github.com/git/git.git git-src && cd >> git-src && make all >> ... The make errored out as before >> > > No error for me. > >> git co 9fca6c && make all >> ... The make errored out as before > > No error for me. > >> >> git co 9fca6c^ && make all >> ... and this compiles to completion >> >> CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22 >> i686 Cygwin > > This is old, do you have the luxury of updating it? > >> >> What else can I do to test this out (I will get a current >> cygwin tomorrow to use in a test). > > I would also check to see if your devel packages are up to date too. You can either upgrade to cygwin 1.17 or higher. Or, if that is really not possible (because you are sitting on a production machine, where no changes are allowed), You can enable this in Makefile: CYGWIN_V15_WIN32API = YesPlease HTH /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: Stephen & Linda Smith > Sent: Sunday, January 06, 2013 1:21 > > > Was it the commit before > > 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it > > 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I > am doing a > > cygwin update presently to look at it. > > Since the email earlier today, I had blown away the > directory. I just now > did the following > > git clone https://github.com/git/git.git git-src && cd > git-src && make all > ... The make errored out as before > No error for me. > git co 9fca6c && make all > ... The make errored out as before No error for me. > > git co 9fca6c^ && make all > ... and this compiles to completion > > CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22 > i686 Cygwin This is old, do you have the luxury of updating it? > > What else can I do to test this out (I will get a current > cygwin tomorrow to use in a test). I would also check to see if your devel packages are up to date too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Version 1.8.1 does not compile on Cygwin 1.7.14
> Was it the commit before > 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was > it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I > am doing a cygwin update presently to look at it. Since the email earlier today, I had blown away the directory. I just now did the following git clone https://github.com/git/git.git git-src && cd git-src && make all ... The make errored out as before git co 9fca6c && make all ... The make errored out as before git co 9fca6c^ && make all ... and this compiles to completion CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22 i686 Cygwin What else can I do to test this out (I will get a current cygwin tomorrow to use in a test). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: Jason Pyeron > Sent: Saturday, January 05, 2013 22:38 > > > > Stephen & Linda Smith > > Sent: Saturday, January 05, 2013 21:05 > > > > Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message > states that > > the macro was being renamed for clarity. The patch also changes a > > define. > > Was it the commit before > 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was > it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I > am doing a cygwin update presently to look at it. > > > > > This change causes the code to not compile on cygwin 1.7.14. > > > > I narrowed the problem to this patch by bisecting commits between > > v1.8.0 and > > 1.8.1 > > > > Here is the error sequence: Cannot reproduce on head and current cygwin, more details please. > > > > CC compat/cygwin.o > > In file included from compat/../git-compat-util.h:90, > > from compat/cygwin.c:9: > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:103:2: > > warning: #warning "fd_set and associated macros have been > > defined in sys/types. > > This may cause runtime problems with W32 sockets" > > In file included from /usr/include/sys/socket.h:16, > > from compat/../git-compat-util.h:131, > > from compat/cygwin.c:9: > > /usr/include/cygwin/socket.h:29: error: redefinition of `struct > > sockaddr' > > /usr/include/cygwin/socket.h:41: error: redefinition of `struct > > sockaddr_storage' > > In file included from /usr/include/sys/socket.h:16, > > from compat/../git-compat-util.h:131, > > from compat/cygwin.c:9: > > /usr/include/cygwin/socket.h:59: error: redefinition of `struct > > linger' > > In file included from compat/../git-compat-util.h:131, > > from compat/cygwin.c:9: > > /usr/include/sys/socket.h:30: error: conflicting types for 'accept' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:536: > > error: previous declaration of 'accept' was here > > /usr/include/sys/socket.h:30: error: conflicting types for 'accept' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:536: jpyeron@porsche /projects/git/git $ make && uname -a && git status && git log --oneline | head -n1 GEN perl/PM.stamp SUBDIR gitweb SUBDIR ../ make[2]: `GIT-VERSION-FILE' is up to date. GEN git-instaweb BUILTIN all SUBDIR git-gui SUBDIR gitk-git make[1]: Nothing to be done for `all'. SUBDIR perl SUBDIR git_remote_helpers SUBDIR templates CYGWIN_NT-5.2-WOW64 porsche 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin # On branch master nothing to commit (working directory clean) 3e293fb Update draft release notes to 1.8.2 > > error: previous declaration of 'accept' was here > > /usr/include/sys/socket.h:32: error: conflicting types for 'bind' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:537: > > error: previous declaration of 'bind' was here > > /usr/include/sys/socket.h:32: error: conflicting types for 'bind' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:537: > > error: previous declaration of 'bind' was here > > /usr/include/sys/socket.h:33: error: conflicting types for 'connect' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:539: > > error: previous declaration of 'connect' was here > > /usr/include/sys/socket.h:33: error: conflicting types for 'connect' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:539: > > error: previous declaration of 'connect' was here > > /usr/include/sys/socket.h:34: error: conflicting types for > > 'getpeername' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:541: > > error: previous declaration of 'getpeername' was here > > /usr/include/sys/socket.h:34: error: conflicting types for > > 'getpeername' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:541: > > error: previous declaration of 'getpeername' was here > > /usr/include/sys/socket.h:35: error: conflicting types for > > 'getsockname' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:542: > > error: previous declaration of 'getsockname' was here > > /usr/include/sys/socket.h:35: error: conflicting types for > > 'getsockname' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:542: > > error: previous declaration of 'getsockname' was here > > /usr/include/sys/socket.h:36: error: conflicting types for 'listen' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:546: > > error: previous declaration of 'listen' was here > > /usr/include/sys/socket.h:36: error: conflicting types for 'listen' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:546: > > error: previous declaration of
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
> Stephen & Linda Smith > Sent: Saturday, January 05, 2013 21:05 > > Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message > states that the macro was being renamed for clarity. The > patch also changes a define. Was it the commit before 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I am doing a cygwin update presently to look at it. > > This change causes the code to not compile on cygwin 1.7.14. > > I narrowed the problem to this patch by bisecting commits > between v1.8.0 and > 1.8.1 > > Here is the error sequence: > > CC compat/cygwin.o > In file included from compat/../git-compat-util.h:90, > from compat/cygwin.c:9: > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:103:2: > warning: #warning "fd_set and associated macros have been > defined in sys/types. > This may cause runtime problems with W32 sockets" > In file included from /usr/include/sys/socket.h:16, > from compat/../git-compat-util.h:131, > from compat/cygwin.c:9: > /usr/include/cygwin/socket.h:29: error: redefinition of > `struct sockaddr' > /usr/include/cygwin/socket.h:41: error: redefinition of > `struct sockaddr_storage' > In file included from /usr/include/sys/socket.h:16, > from compat/../git-compat-util.h:131, > from compat/cygwin.c:9: > /usr/include/cygwin/socket.h:59: error: redefinition of > `struct linger' > In file included from compat/../git-compat-util.h:131, > from compat/cygwin.c:9: > /usr/include/sys/socket.h:30: error: conflicting types for 'accept' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:536: > error: previous declaration of 'accept' was here > /usr/include/sys/socket.h:30: error: conflicting types for 'accept' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:536: > error: previous declaration of 'accept' was here > /usr/include/sys/socket.h:32: error: conflicting types for 'bind' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:537: > error: previous declaration of 'bind' was here > /usr/include/sys/socket.h:32: error: conflicting types for 'bind' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:537: > error: previous declaration of 'bind' was here > /usr/include/sys/socket.h:33: error: conflicting types for 'connect' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:539: > error: previous declaration of 'connect' was here > /usr/include/sys/socket.h:33: error: conflicting types for 'connect' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:539: > error: previous declaration of 'connect' was here > /usr/include/sys/socket.h:34: error: conflicting types for > 'getpeername' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:541: > error: previous declaration of 'getpeername' was here > /usr/include/sys/socket.h:34: error: conflicting types for > 'getpeername' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:541: > error: previous declaration of 'getpeername' was here > /usr/include/sys/socket.h:35: error: conflicting types for > 'getsockname' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:542: > error: previous declaration of 'getsockname' was here > /usr/include/sys/socket.h:35: error: conflicting types for > 'getsockname' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:542: > error: previous declaration of 'getsockname' was here > /usr/include/sys/socket.h:36: error: conflicting types for 'listen' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:546: > error: previous declaration of 'listen' was here > /usr/include/sys/socket.h:36: error: conflicting types for 'listen' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:546: > error: previous declaration of 'listen' was here > /usr/include/sys/socket.h:37: error: conflicting types for 'recv' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:547: > error: previous declaration of 'recv' was here > /usr/include/sys/socket.h:37: error: conflicting types for 'recv' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:547: > error: previous declaration of 'recv' was here > /usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:548: > error: previous declaration of 'recvfrom' was here > /usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:548: > error: previous declaration of 'recvfrom' was here > /usr/include/sys/socket.h:41: error: conflicting types for 'send' > /usr/lib/gcc/i686-pc-cygwin/3.4
Version 1.8.1 does not compile on Cygwin 1.7.14
Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message states that the macro was being renamed for clarity. The patch also changes a define. This change causes the code to not compile on cygwin 1.7.14. I narrowed the problem to this patch by bisecting commits between v1.8.0 and 1.8.1 Here is the error sequence: CC compat/cygwin.o In file included from compat/../git-compat-util.h:90, from compat/cygwin.c:9: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: warning: #warning "fd_set and associated macros have been defined in sys/types. This may cause runtime problems with W32 sockets" In file included from /usr/include/sys/socket.h:16, from compat/../git-compat-util.h:131, from compat/cygwin.c:9: /usr/include/cygwin/socket.h:29: error: redefinition of `struct sockaddr' /usr/include/cygwin/socket.h:41: error: redefinition of `struct sockaddr_storage' In file included from /usr/include/sys/socket.h:16, from compat/../git-compat-util.h:131, from compat/cygwin.c:9: /usr/include/cygwin/socket.h:59: error: redefinition of `struct linger' In file included from compat/../git-compat-util.h:131, from compat/cygwin.c:9: /usr/include/sys/socket.h:30: error: conflicting types for 'accept' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: error: previous declaration of 'accept' was here /usr/include/sys/socket.h:30: error: conflicting types for 'accept' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: error: previous declaration of 'accept' was here /usr/include/sys/socket.h:32: error: conflicting types for 'bind' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:537: error: previous declaration of 'bind' was here /usr/include/sys/socket.h:32: error: conflicting types for 'bind' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:537: error: previous declaration of 'bind' was here /usr/include/sys/socket.h:33: error: conflicting types for 'connect' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:539: error: previous declaration of 'connect' was here /usr/include/sys/socket.h:33: error: conflicting types for 'connect' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:539: error: previous declaration of 'connect' was here /usr/include/sys/socket.h:34: error: conflicting types for 'getpeername' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:541: error: previous declaration of 'getpeername' was here /usr/include/sys/socket.h:34: error: conflicting types for 'getpeername' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:541: error: previous declaration of 'getpeername' was here /usr/include/sys/socket.h:35: error: conflicting types for 'getsockname' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:542: error: previous declaration of 'getsockname' was here /usr/include/sys/socket.h:35: error: conflicting types for 'getsockname' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:542: error: previous declaration of 'getsockname' was here /usr/include/sys/socket.h:36: error: conflicting types for 'listen' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:546: error: previous declaration of 'listen' was here /usr/include/sys/socket.h:36: error: conflicting types for 'listen' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:546: error: previous declaration of 'listen' was here /usr/include/sys/socket.h:37: error: conflicting types for 'recv' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:547: error: previous declaration of 'recv' was here /usr/include/sys/socket.h:37: error: conflicting types for 'recv' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:547: error: previous declaration of 'recv' was here /usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:548: error: previous declaration of 'recvfrom' was here /usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:548: error: previous declaration of 'recvfrom' was here /usr/include/sys/socket.h:41: error: conflicting types for 'send' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:549: error: previous declaration of 'send' was here /usr/include/sys/socket.h:41: error: conflicting types for 'send' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:549: error: previous declaration of 'send' was here /usr/include/sys/socket.h:44: error: conflicting types for 'sendto' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:550: error: previous declaration of 'sendt