[PATCH v2] MinGW(-W64) cross-compilation

[PATCH v2] MinGW(-W64) cross-compilation

[Marat Radchenko]

Differences with v1:
 - Dropped "MINGW: compat/bswap.h: include stdint.h", it isn't needed after
   "MINGW: git-compat-util.h: use inttypes.h for printf macros"
 - Split "MINGW: config.mak.uname allow using CURL for non-msysGit builds"
   into "MINGW: config.mak.uname: allow using cURL for non-msysGit builds"
   and "MINGW: fix main() signature in http-fetch.c and remote-curl.c"
 - Reworded "MINGW: git-compat-util.h: use inttypes.h for printf macros"
 - Reworded "MINGW: config.mak.uname: reorganize MINGW settings"
 - Rewrote "MINGW: config.mak.uname: drop -DNOGDI" into
   "MINGW: compat/poll/poll.c: undef NOGDI"
 - Rewrote "MINGW: config.mak.uname: drop USE_NED_ALLOCATOR" into
   "compat/nedmalloc/malloc.c.h: fix compilation under MinGW-W64"
 - Reworded "Makefile: introduce CROSS_COMPILE variable"
 - Reordeder commits (1-5 are Acked by: Eric Faye-Lund <kusmabite@gmail.com>)

=====================================

This patch series fixes building on modern MinGW and (32bit only yet) MinGW-W64.

*Compilation* tested on:
 - MSVC (via WinGit environment)
 - msysGit environment
 - Linux cross-toolchain i686-pc-mingw32 (4.8.2) with mingw-runtime-3.20.2
 - Linux cross-toolchain i686-w64-mingw32 (4.8.2) with mingw64-runtime-3.1.0

Stuff still required to make Git build with x86_64 MinGW-W64 toolchain:

1. Drop -D_USE_32BIT_TIME_T that was added in fa93bb to config.mak.uname
because time_t cannot be 32bit on x86_64. I haven't yet figured out what
should break if this define is removed (pointers are welcome) and why it was
added in the first place.

2. Stop passing --large-address-aware to linker. I wonder if it does anything
for 32bit MinGW builds.

3. Fix several places with mismatched pointer size casts.

Building it from Gentoo Linux:

MinGW:

  crossdev -t i686-pc-mingw32
  ARCH=x86 emerge-i686-pc-mingw32 -u dev-libs/libiconv sys-libs/zlib net-misc/curl sys-devel/gettext expat
  cd <git>
  make CROSS_COMPILE=i686-pc-mingw32- NO_OPENSSL=1 MINGW=1 CURLDIR=/usr/i686-pc-mingw32/usr

MinGW-W64 (32 bit):

  crossdev -t i686-w64-mingw32
  ARCH=x86 emerge-i686-w64-mingw32 -u dev-libs/libiconv sys-libs/zlib net-misc/curl sys-devel/gettext expat
  cd <git>
  make CROSS_COMPILE=i686-w64-mingw32- NO_OPENSSL=1 MINGW=1 CURLDIR=/usr/i686-w64-mingw32/usr

[PATCH 01/12] MINGW: compat/mingw.h: do not attempt to redefine lseek on mingw-w64

[Marat Radchenko]

Unlike MinGW, MinGW-W64 has lseek already properly defined in io.h.

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
Acked-by: Eric Faye-Lund <kusmabite@gmail.com>
---
 compat/mingw.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/compat/mingw.h b/compat/mingw.h
index e033e72..262b300 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -265,7 +265,9 @@ static inline int getrlimit(int resource, struct rlimit *rlp)
  * Use mingw specific stat()/lstat()/fstat() implementations on Windows.
  */
 #define off_t off64_t
+#ifndef lseek
 #define lseek _lseeki64
+#endif
 
 /* use struct stat with 64 bit st_size */
 #ifdef stat
-- 
1.9.1

[PATCH 02/12] MSVC: config.mak.uname: drop -D__USE_MINGW_ACCESS from CFLAGS

[Marat Radchenko]

-D__USE_MINGW_ACCESS only affects MinGW and does nothing when
MSVC is used.

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
Acked-by: Eric Faye-Lund <kusmabite@gmail.com>
---
 config.mak.uname | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.mak.uname b/config.mak.uname
index 23a8803..faddb82 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -357,7 +357,7 @@ ifeq ($(uname_S),Windows)
 	COMPAT_OBJS = compat/msvc.o compat/winansi.o \
 		compat/win32/pthread.o compat/win32/syslog.o \
 		compat/win32/dirent.o
-	COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
+	COMPAT_CFLAGS = -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
 	BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib
 	EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib invalidcontinue.obj
 	PTHREAD_LIBS =
-- 
1.9.1

[PATCH 03/12] MINGW: compat/mingw.h: drop fork() definition

[Marat Radchenko]

fork() is not used in MinGW builds but causes a compiler warning
on x86_64 MinGW-W64: conflicting types for built-in function 'fork'

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
Acked-by: Eric Faye-Lund <kusmabite@gmail.com>
---
 compat/mingw.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/compat/mingw.h b/compat/mingw.h
index 262b300..87d58ba 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -90,8 +90,6 @@ static inline int symlink(const char *oldpath, const char *newpath)
 { errno = ENOSYS; return -1; }
 static inline int fchmod(int fildes, mode_t mode)
 { errno = ENOSYS; return -1; }
-static inline pid_t fork(void)
-{ errno = ENOSYS; return -1; }
 static inline unsigned int alarm(unsigned int seconds)
 { return 0; }
 static inline int fsync(int fd)
-- 
1.9.1

[PATCH 04/12] MINGW: do not fail at redefining pid_t on MinGW-W64

[Marat Radchenko]

pid_t is available in sys/types.h on both MinGW and MinGW-W64

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
Acked-by: Eric Faye-Lund <kusmabite@gmail.com>
---
 compat/mingw.h | 1 -
 compat/msvc.h  | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/compat/mingw.h b/compat/mingw.h
index 87d58ba..7e3d038 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -5,7 +5,6 @@
  * things that are not available in header files
  */
 
-typedef int pid_t;
 typedef int uid_t;
 typedef int socklen_t;
 #define hstrerror strerror
diff --git a/compat/msvc.h b/compat/msvc.h
index 580bb55..a63d878 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -15,6 +15,8 @@
 #define strtoull     _strtoui64
 #define strtoll      _strtoi64
 
+typedef int pid_t;
+
 static __inline int strcasecmp (const char *s1, const char *s2)
 {
 	int size1 = strlen(s1);
-- 
1.9.1

[PATCH 05/12] MINGW: config.mak.uname: allow using cURL for non-msysGit builds

[Marat Radchenko]

Is it absolutely valid and possible to have cURL in generic
MinGW environment. Building Git without cURL is still possible
by passing NO_CURL=1

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
Acked-by: Eric Faye-Lund <kusmabite@gmail.com>
---
 config.mak.uname | 2 --
 1 file changed, 2 deletions(-)

diff --git a/config.mak.uname b/config.mak.uname
index faddb82..a626410 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -519,8 +519,6 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
 	INTERNAL_QSORT = YesPlease
 	HAVE_LIBCHARSET_H = YesPlease
 	NO_GETTEXT = YesPlease
-else
-	NO_CURL = YesPlease
 endif
 endif
 ifeq ($(uname_S),QNX)
-- 
1.9.1

[PATCH 06/12] MINGW: git-compat-util.h: use inttypes.h for printf macros

[Marat Radchenko]

All MinGW flavors have inttypes.h, so just include it.

However, we need to pass -D__USE_MINGW_ANSI_STDIO=0 to select
MSVCRT-compatible macro definitions on MinGW-W64:
http://sourceforge.net/apps/trac/mingw-w64/wiki/gnu%20printf

As a side-effect, Git no longer builds with MSVC < 2010 due to
its lack of stdint.h but hopefully that is not a problem.

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
---
 compat/mingw.h    |  2 --
 compat/msvc.h     |  3 +++
 config.mak.uname  |  3 ++-
 git-compat-util.h | 11 ++++++-----
 4 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/compat/mingw.h b/compat/mingw.h
index 7e3d038..2fbc8ea 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -339,8 +339,6 @@ static inline char *mingw_find_last_dir_sep(const char *path)
 }
 #define find_last_dir_sep mingw_find_last_dir_sep
 #define PATH_SEP ';'
-#define PRIuMAX "I64u"
-#define PRId64 "I64d"
 
 void mingw_open_html(const char *path);
 #define open_html mingw_open_html
diff --git a/compat/msvc.h b/compat/msvc.h
index a63d878..84a03f9 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -17,6 +17,9 @@
 
 typedef int pid_t;
 
+#define PRIuMAX "I64u"
+#define PRId64 "I64d"
+
 static __inline int strcasecmp (const char *s1, const char *s2)
 {
 	int size1 = strlen(s1);
diff --git a/config.mak.uname b/config.mak.uname
index a626410..50c1114 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -316,6 +316,7 @@ ifeq ($(uname_S),Windows)
 	NO_PREAD = YesPlease
 	NEEDS_CRYPTO_WITH_SSL = YesPlease
 	NO_LIBGEN_H = YesPlease
+	NO_INTTYPES_H = UnfortunatelyYes
 	NO_POLL = YesPlease
 	NO_SYMLINK_HEAD = YesPlease
 	NO_IPV6 = YesPlease
@@ -497,7 +498,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
 	NO_INET_NTOP = YesPlease
 	NO_POSIX_GOODIES = UnfortunatelyYes
 	DEFAULT_HELP_FORMAT = html
-	COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -D_USE_32BIT_TIME_T -DNOGDI -Icompat -Icompat/win32
+	COMPAT_CFLAGS += -D__USE_MINGW_ANSI_STDIO=0 -D__USE_MINGW_ACCESS -D_USE_32BIT_TIME_T -DNOGDI -Icompat -Icompat/win32
 	COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
 	COMPAT_OBJS += compat/mingw.o compat/winansi.o \
 		compat/win32/pthread.o compat/win32/syslog.o \
diff --git a/git-compat-util.h b/git-compat-util.h
index f6d3a46..65498a2 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -95,6 +95,12 @@
 #define GIT_WINDOWS_NATIVE
 #endif
 
+#ifndef NO_INTTYPES_H
+#include <inttypes.h>
+#else
+#include <stdint.h>
+#endif
+
 #include <unistd.h>
 #include <stdio.h>
 #include <sys/stat.h>
@@ -146,11 +152,6 @@
 #include <netdb.h>
 #include <pwd.h>
 #include <sys/un.h>
-#ifndef NO_INTTYPES_H
-#include <inttypes.h>
-#else
-#include <stdint.h>
-#endif
 #ifdef NO_INTPTR_T
 /*
  * On I16LP32, ILP32 and LP64 "long" is the save bet, however
-- 
1.9.1

[PATCH 07/12] MINGW: config.mak.uname: reorganize MINGW settings

[Marat Radchenko]

HAVE_LIBCHARSET_H and NO_R_TO_GCC_LINKER are not specific to
msysGit, they're general MinGW settings.

Logic behind HAVE_LIBCHARSET_H: if user is on MinGW and has iconv,
we expect him to have libcharset.h. If user doesn't have iconv,
he has to explicitly say so via NO_ICONV=1.

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
---
 config.mak.uname | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config.mak.uname b/config.mak.uname
index 50c1114..b68a7d1 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -516,11 +516,11 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
 	prefix =
 	INSTALL = /bin/install
 	EXTLIBS += /mingw/lib/libz.a
-	NO_R_TO_GCC_LINKER = YesPlease
 	INTERNAL_QSORT = YesPlease
-	HAVE_LIBCHARSET_H = YesPlease
 	NO_GETTEXT = YesPlease
 endif
+	HAVE_LIBCHARSET_H = YesPlease
+	NO_R_TO_GCC_LINKER = YesPlease
 endif
 ifeq ($(uname_S),QNX)
 	COMPAT_CFLAGS += -DSA_RESTART=0
-- 
1.9.1

[PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c

[Marat Radchenko]

On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
Fix `warning: passing argument 2 of 'mingw_main' from incompatible
pointer type` in http-fetch.c and remote-curl.c by dropping 'const'.

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
---
 http-fetch.c  | 5 +++--
 remote-curl.c | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/http-fetch.c b/http-fetch.c
index ba3ea10..a6a9a2f 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -6,7 +6,7 @@
 static const char http_fetch_usage[] = "git http-fetch "
 "[-c] [-t] [-a] [-v] [--recover] [-w ref] [--stdin] commit-id url";
 
-int main(int argc, const char **argv)
+int main(int argc, char **argv)
 {
 	struct walker *walker;
 	int commits_on_stdin = 0;
@@ -38,7 +38,8 @@ int main(int argc, const char **argv)
 		} else if (argv[arg][1] == 'v') {
 			get_verbosely = 1;
 		} else if (argv[arg][1] == 'w') {
-			write_ref = &argv[arg + 1];
+			const char *ref = argv[arg + 1];
+			write_ref = &ref;
 			arg++;
 		} else if (argv[arg][1] == 'h') {
 			usage(http_fetch_usage);
diff --git a/remote-curl.c b/remote-curl.c
index 52c2d96..565b6c9 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -938,7 +938,7 @@ static void parse_push(struct strbuf *buf)
 	free(specs);
 }
 
-int main(int argc, const char **argv)
+int main(int argc, char **argv)
 {
 	struct strbuf buf = STRBUF_INIT;
 	int nongit;
-- 
1.9.1

[PATCH 09/12] Makefile: introduce CROSS_COMPILE variable

[Marat Radchenko]

To ease cross-compilation process, introduce a single variable
with the prefix to all compiler-related executables.

Define CROSS_COMPILE=foo- if your compiler and binary utilities
are foo-cc, foo-ar, foo-strip, etc.  More specific variables
override this, so if you set CC=gcc CROSS_COMPILE=ia64-linux-gnu-
then the compiler will be 'gcc', not 'ia64-linux-gnu-gcc'.

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
---
 Makefile         | 19 +++++++++++++------
 config.mak.uname |  2 +-
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index 74a929b..8406b94 100644
--- a/Makefile
+++ b/Makefile
@@ -350,6 +350,11 @@ all::
 #
 # Define GMTIME_UNRELIABLE_ERRORS if your gmtime() function does not
 # return NULL when it receives a bogus time_t.
+#
+# Define CROSS_COMPILE=foo- if your compiler and binary utilities
+# are foo-cc, foo-ar, foo-strip, etc.  More specific variables
+# override this, so if you set CC=gcc CROSS_COMPILE=ia64-linux-gnu-
+# then the compiler will be 'gcc', not 'ia64-linux-gnu-gcc'.
 
 GIT-VERSION-FILE: FORCE
 	@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -361,7 +366,6 @@ CFLAGS = -g -O2 -Wall
 LDFLAGS =
 ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
 ALL_LDFLAGS = $(LDFLAGS)
-STRIP ?= strip
 
 # Among the variables below, these:
 #   gitexecdir
@@ -401,8 +405,12 @@ htmldir_relative = $(patsubst $(prefix)/%,%,$(htmldir))
 
 export prefix bindir sharedir sysconfdir gitwebdir localedir
 
-CC = cc
-AR = ar
+AR = $(CROSS_COMPILE)ar
+CC = $(CROSS_COMPILE)cc
+GCOV = $(CROSS_COMPILE)gcov
+RC = $(CROSS_COMPILE)windres
+STRIP = $(CROSS_COMPILE)strip
+
 RM = rm -f
 DIFF = diff
 TAR = tar
@@ -415,13 +423,12 @@ XGETTEXT = xgettext
 MSGFMT = msgfmt
 PTHREAD_LIBS = -lpthread
 PTHREAD_CFLAGS =
-GCOV = gcov
 
 export TCL_PATH TCLTK_PATH
 
 SPARSE_FLAGS =
 
-
+RCFLAGS =
 
 ### --- END CONFIGURATION SECTION ---
 
@@ -1796,7 +1803,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
 	mv $@+ $@
 
 git.res: git.rc GIT-VERSION-FILE
-	$(QUIET_RC)$(RC) \
+	$(QUIET_RC)$(RC) $(RCFLAGS) \
 	  $(join -DMAJOR= -DMINOR=, $(wordlist 1,2,$(subst -, ,$(subst ., ,$(GIT_VERSION))))) \
 	  -DGIT_VERSION="\\\"$(GIT_VERSION)\\\"" $< -o $@
 
diff --git a/config.mak.uname b/config.mak.uname
index b68a7d1..d5f7953 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -507,7 +507,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
 	EXTLIBS += -lws2_32
 	GITLIBS += git.res
 	PTHREAD_LIBS =
-	RC = windres -O coff
+	RCFLAGS += -O coff
 	NATIVE_CRLF = YesPlease
 	X = .exe
 	SPARSE_FLAGS = -Wno-one-bit-signed-bitfield
-- 
1.9.1

[PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

[Marat Radchenko]

On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI.

Removal -DNOGDI=1 from config.mak.uname has an undesirable effect of
bringing in wingdi.h with weird #define ERROR 0 that conflicts with
internal Git enums. So, just #undef NOGDI in compat/poll/poll.c.

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
---
 compat/poll/poll.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/compat/poll/poll.c b/compat/poll/poll.c
index 31163f2..e38cba8 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -38,6 +38,7 @@
 #include <assert.h>
 
 #if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
+# undef NOGDI
 # define WIN32_NATIVE
 # if defined (_MSC_VER) && !defined(_WIN32_WINNT)
 #  define _WIN32_WINNT 0x0502
-- 
1.9.1

[PATCH 11/12] compat/nedmalloc/malloc.c.h: fix compilation under MinGW-W64

[Marat Radchenko]

1. Unlike MinGW, MinGW-W64 already provides _ReadWriteBarrier macro,
   so don't try to redefine it.

2. MinGW-W64 has a strange definition FORCEINLINE as
   extern __inline__ __attribute__((__always_inline__,__gnu_inline__))

   'extern' doesn't work together with 'static', so #undef MinGW-W64
   version of FORCEINLINE.

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
---
 compat/nedmalloc/malloc.c.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
index f216a2a..a6c8cac 100644
--- a/compat/nedmalloc/malloc.c.h
+++ b/compat/nedmalloc/malloc.c.h
@@ -715,6 +715,10 @@ struct mallinfo {
 #endif /* HAVE_USR_INCLUDE_MALLOC_H */
 #endif /* NO_MALLINFO */
 
+#ifdef __MINGW64_VERSION_MAJOR
+  #undef FORCEINLINE
+#endif
+
 /*
   Try to persuade compilers to inline. The most critical functions for
   inlining are defined as macros, so these aren't used for them.
@@ -1382,7 +1386,9 @@ LONG __cdecl _InterlockedExchange(LONG volatile *Target, LONG Value);
 
   /*** Atomic operations ***/
   #if (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__) > 40100
-    #define _ReadWriteBarrier() __sync_synchronize()
+    #ifndef _ReadWriteBarrier
+      #define _ReadWriteBarrier() __sync_synchronize()
+    #endif
   #else
     static __inline__ __attribute__((always_inline)) long __sync_lock_test_and_set(volatile long * const Target, const long Value)
     {
-- 
1.9.1

[PATCH 12/12] MINGW: config.mak.uname: add explicit way to request MinGW-build

[Marat Radchenko]

When crosscompiling, one cannot rely on `uname` from host system.
Thus, add an option to use `make MINGW=1` for building MinGW build
from non-MinGW host (Linux, for example).

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
---
 config.mak.uname | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/config.mak.uname b/config.mak.uname
index d5f7953..c7f3d74 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -13,6 +13,11 @@ ifdef MSVC
 	uname_O := Windows
 endif
 
+ifdef MINGW
+	uname_S := MINGW
+	uname_O := MINGW
+endif
+
 # We choose to avoid "if .. else if .. else .. endif endif"
 # because maintaining the nesting to match is a pain.  If
 # we had "elif" things would have been much nicer...
-- 
1.9.1

Re: [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c

[Karsten Blees]

Am 29.04.2014 11:12, schrieb Marat Radchenko:
> On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
> Fix `warning: passing argument 2 of 'mingw_main' from incompatible
> pointer type` in http-fetch.c and remote-curl.c by dropping 'const'.
> 

Would you mind cross checking your changes with the msysgit fork? Fixing the same thing in a slightly different manner will just cause unnecessary conflicts (i.e. unnecessary work for the Git for Windows maintainers, as well as for you to come up with an alternate solution for something that's long been fixed).

See https://github.com/msysgit/git/commit/9206e7fd (squashed from https://github.com/msysgit/git/commit/0115ef83 and https://github.com/msysgit/git/commit/6949537a).
 

Re: [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c

[Erik Faye-Lund]

On Wed, Apr 30, 2014 at 10:35 AM, Karsten Blees <karsten.blees@gmail.com> wrote:
> Am 29.04.2014 11:12, schrieb Marat Radchenko:
>> On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
>> Fix `warning: passing argument 2 of 'mingw_main' from incompatible
>> pointer type` in http-fetch.c and remote-curl.c by dropping 'const'.
>>
>
> Would you mind cross checking your changes with the msysgit fork? Fixing the same thing in a slightly different manner will just cause unnecessary conflicts (i.e. unnecessary work for the Git for Windows maintainers, as well as for you to come up with an alternate solution for something that's long been fixed).
>
> See https://github.com/msysgit/git/commit/9206e7fd (squashed from https://github.com/msysgit/git/commit/0115ef83 and https://github.com/msysgit/git/commit/6949537a).
>

While it's certainly a good point, I think this is *our* fault for not
upstreaming our changes, and the responsibility of cleaning up merges
should lie on our shoulders. We've diverged a lot. Sure, Dscho does a
great job making the divergence less painful, but IMO we should try to
reduce the delta as well.

For instance, I think the Unicode-support patches have proven
themselves by now and should go upstream. And there's probably a ton
of smaller free-standing clean-ups that could get the same treatment.

Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

[Stepan Kasal]

Hello,

On Tue, Apr 29, 2014 at 01:12:04PM +0400, Marat Radchenko wrote:
> On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI.
> 
> Removal -DNOGDI=1 from config.mak.uname has an undesirable effect of
> bringing in wingdi.h with weird #define ERROR 0 that conflicts with
> internal Git enums. So, just #undef NOGDI in compat/poll/poll.c.

compat/poll/poll.c comes from Gnulib, so it would be better to submit
the patch there and then backport so that the divergence of the two
versions does not get worse.

Stepan

Re: [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c

[Johannes Schindelin]

Hi kusma,

On Wed, 30 Apr 2014, Erik Faye-Lund wrote:

> While it's certainly a good point, I think this is *our* fault for not
> upstreaming our changes, and the responsibility of cleaning up merges
> should lie on our shoulders. We've diverged a lot. Sure, Dscho does a
> great job making the divergence less painful, but IMO we should try to
> reduce the delta as well.

Just for historical context: we *did* try to get our changes upstream. In
fact, that was in large part everything Steffen Prohaska did while he was
maintaining Git for Windows. The going has been tough, though, to the
point that we were losing contributors who were not *quite* willing to put
up with such a detailed vetting process as the Git mailing list requires.

I have to admit that it is really, really hard even for someone like me,
who is used to the ways of the Git mailing list, because just a simple
thing like this curl-config issue already eats up several days of my Git
time budget.

So while I am sympathetic to the point of view that the Git for Windows
project failed to upstream its changes, I am *equally* sympathetic to the
point of view that it is an undue burden to have to go through the process
of getting patches included by upstream Git. I, for one, simply ain't got
the time, man.

Ciao,
Johannes

Re: [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c

[Felipe Contreras]

Johannes Schindelin wrote:
> On Wed, 30 Apr 2014, Erik Faye-Lund wrote:
> 
> > While it's certainly a good point, I think this is *our* fault for not
> > upstreaming our changes, and the responsibility of cleaning up merges
> > should lie on our shoulders. We've diverged a lot. Sure, Dscho does a
> > great job making the divergence less painful, but IMO we should try to
> > reduce the delta as well.
> 
> Just for historical context: we *did* try to get our changes upstream. In
> fact, that was in large part everything Steffen Prohaska did while he was
> maintaining Git for Windows. The going has been tough, though, to the
> point that we were losing contributors who were not *quite* willing to put
> up with such a detailed vetting process as the Git mailing list requires.
> 
> I have to admit that it is really, really hard even for someone like me,
> who is used to the ways of the Git mailing list, because just a simple
> thing like this curl-config issue already eats up several days of my Git
> time budget.
> 
> So while I am sympathetic to the point of view that the Git for Windows
> project failed to upstream its changes, I am *equally* sympathetic to the
> point of view that it is an undue burden to have to go through the process
> of getting patches included by upstream Git. I, for one, simply ain't got
> the time, man.

As a maintainer of another friendly fork of Git (or downstream), because
of very similar reaons, I symphathize.

It's something that has to be done though, otherwise the burden of
maintaining the friendly fork becomse unberable.

The trick is to only send the trivial patches upstream, and also to
constantly keep track of what is missing from upstream.

In oder to do this I've found invaluable to have an integration branch,
which I constnatly regenerate with `git reintegrate`[1]. IIRC you do a
similar kind of reintegration for each new release of msysgit, and it
appears to me that you do it by hand, which must be tedious.

I'm planning to write a blog post about the subject, but basically I
have a bunch of branches that are direct descendants of an upstream
version, I tell `git reintegrate` to merge them on top of certain
upstream release, the result must match *exactly* what my main master
branch has. The descendant branches I constanly keep rebasing, and the
main master branch always mergering and cherry-picking, never rebasing.

[1] https://github.com/felipec/git-reintegrate

-- 
Felipe Contreras

Re: [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c

[Stepan Kasal]

Hello,

On Wed, Apr 30, 2014 at 10:35:56AM +0200, Karsten Blees wrote:
> Would you mind cross checking your changes with the msysgit fork?
> [...]
> See https://github.com/msysgit/git/commit/9206e7fd (squashed from
> https://github.com/msysgit/git/commit/0115ef83 and
> https://github.com/msysgit/git/commit/6949537a).

OK, I _did_ checked these, let's look at the two original commits:

- 0115ef83 is interesting, but not relevant to the warnings,
- 6949537a contains a fix for the const warning, plus it fixed a
  minor nit in the other commit.

> [...] you to come up with an
> alternate solution for something that's long been fixed).

Long been fixed by a quick and dirty hack.
Marat's fix is nicer, can I ask some of the msysGit guys to ack it?
(Appended below for the new cc's here.)

Have a nice day,
	Stepan

PS: I bet Dscho will be able to handle the conflict.

From: Marat Radchenko <marat@slonopotamus.org>
Subject: [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c
Date: Tue, 29 Apr 2014 13:12:02 +0400

On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
Fix `warning: passing argument 2 of 'mingw_main' from incompatible
pointer type` in http-fetch.c and remote-curl.c by dropping 'const'.

Signed-off-by: Marat Radchenko <marat@slonopotamus.org>
---
 http-fetch.c  | 5 +++--
 remote-curl.c | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/http-fetch.c b/http-fetch.c
index ba3ea10..a6a9a2f 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -6,7 +6,7 @@
 static const char http_fetch_usage[] = "git http-fetch "
 "[-c] [-t] [-a] [-v] [--recover] [-w ref] [--stdin] commit-id url";
 
-int main(int argc, const char **argv)
+int main(int argc, char **argv)
 {
 	struct walker *walker;
 	int commits_on_stdin = 0;
@@ -38,7 +38,8 @@ int main(int argc, const char **argv)
 		} else if (argv[arg][1] == 'v') {
 			get_verbosely = 1;
 		} else if (argv[arg][1] == 'w') {
-			write_ref = &argv[arg + 1];
+			const char *ref = argv[arg + 1];
+			write_ref = &ref;
 			arg++;
 		} else if (argv[arg][1] == 'h') {
 			usage(http_fetch_usage);
diff --git a/remote-curl.c b/remote-curl.c
index 52c2d96..565b6c9 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -938,7 +938,7 @@ static void parse_push(struct strbuf *buf)
 	free(specs);
 }
 
-int main(int argc, const char **argv)
+int main(int argc, char **argv)
 {
 	struct strbuf buf = STRBUF_INIT;
 	int nongit;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH] Win32: move main macro to a function

[Stepan Kasal]

From: Karsten Blees <blees@dcon.de>
Date: Fri, 7 Jan 2011 19:47:23 +0100

The code in the MinGW main macro is getting more and more complex,
move to a separate initialization function for readabiliy and
extensibility.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
---

Hello,
  this is commit 0115ef83 alias 9206e7fd that Karsten mentioned.

Junio, this one has been in msysgit for 2 or 3 years, so you can
suppose it is acked.

Have a nice day,
	Stepan

 compat/mingw.c | 15 +++++++++++++++
 compat/mingw.h | 16 +++++-----------
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index e9892f8..1d11e9f 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1823,3 +1823,18 @@ pid_t waitpid(pid_t pid, int *status, int options)
 	errno = EINVAL;
 	return -1;
 }
+
+void mingw_startup()
+{
+	/* copy executable name to argv[0] */
+	__argv[0] = xstrdup(_pgmptr);
+
+	/* initialize critical section for waitpid pinfo_t list */
+	InitializeCriticalSection(&pinfo_cs);
+
+	/* set up default file mode and file modes for stdin/out/err */
+	_fmode = _O_BINARY;
+	_setmode(_fileno(stdin), _O_BINARY);
+	_setmode(_fileno(stdout), _O_BINARY);
+	_setmode(_fileno(stderr), _O_BINARY);
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index e033e72..95bcc75 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -361,22 +361,16 @@ void free_environ(char **env);
 extern CRITICAL_SECTION pinfo_cs;
 
 /*
- * A replacement of main() that ensures that argv[0] has a path
- * and that default fmode and std(in|out|err) are in binary mode
+ * A replacement of main() that adds win32 specific initialization.
  */
 
+void mingw_startup();
 #define main(c,v) dummy_decl_mingw_main(); \
 static int mingw_main(c,v); \
-int main(int argc, char **argv) \
+int main(c,v) \
 { \
-	extern CRITICAL_SECTION pinfo_cs; \
-	_fmode = _O_BINARY; \
-	_setmode(_fileno(stdin), _O_BINARY); \
-	_setmode(_fileno(stdout), _O_BINARY); \
-	_setmode(_fileno(stderr), _O_BINARY); \
-	argv[0] = xstrdup(_pgmptr); \
-	InitializeCriticalSection(&pinfo_cs); \
-	return mingw_main(argc, argv); \
+	mingw_startup(); \
+	return mingw_main(__argc, __argv); \
 } \
 static int mingw_main(c,v)
 

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

[Marat Radchenko]

On Wed, Apr 30, 2014 at 01:41:25PM +0200, Stepan Kasal wrote:
> Hello,
> 
> On Tue, Apr 29, 2014 at 01:12:04PM +0400, Marat Radchenko wrote:
> > On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI.
> > 
> > Removal -DNOGDI=1 from config.mak.uname has an undesirable effect of
> > bringing in wingdi.h with weird #define ERROR 0 that conflicts with
> > internal Git enums. So, just #undef NOGDI in compat/poll/poll.c.
> 
> compat/poll/poll.c comes from Gnulib, so it would be better to submit
> the patch there and then backport so that the divergence of the two
> versions does not get worse.

That's why v1 of this patch [1] didn't touch poll.c at all.
I don't think it's gnulib problem that combination of two third-parties
(git and mingw-w64) set up such conditions where poll.c fails to compile.

If one wants to dig deeper, I'd say the problem is in MinGW-W64 headers
because their behavior of hiding MsgWaitForMultipleObjects doesn't
match behavior of MSVC headers.

Re: [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c

[Marat Radchenko]

On Wed, Apr 30, 2014 at 10:35:56AM +0200, Karsten Blees wrote:
> Am 29.04.2014 11:12, schrieb Marat Radchenko:
> > On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
> > Fix `warning: passing argument 2 of 'mingw_main' from incompatible
> > pointer type` in http-fetch.c and remote-curl.c by dropping 'const'.
> > 
> 
> Would you mind cross checking your changes with the msysgit fork?
> Fixing the same thing in a slightly different manner will just cause
> unnecessary conflicts (i.e. unnecessary work for the Git for Windows
> maintainers, as well as for you to come up with an alternate solution
> for something that's long been fixed).
>
> See https://github.com/msysgit/git/commit/9206e7fd (squashed from
> https://github.com/msysgit/git/commit/0115ef83 and
> https://github.com/msysgit/git/commit/6949537a). 

6949537a is just an unnecessary hack and would have to be rewritten
no matter who would try to submit it upstream.

Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

[Stepan Kasal]

Hello Marat,

On Sat, May 03, 2014 at 11:00:51AM +0400, Marat Radchenko wrote:
> On Wed, Apr 30, 2014 at 01:41:25PM +0200, Stepan Kasal wrote:
> > On Tue, Apr 29, 2014 at 01:12:04PM +0400, Marat Radchenko wrote:
> > > On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI.
> > > 
> > > Removal -DNOGDI=1 from config.mak.uname has an undesirable effect of
[..]
> > 
> > compat/poll/poll.c comes from Gnulib, so it would be better to submit
[..]
> 
> That's why v1 of this patch [1] didn't touch poll.c at all.

ouch!  It looks like you everyone sending you elsewhere.  I apologize
for being part of that.  (I was not aware about the previous version.)

> I don't think it's gnulib problem that combination of two third-parties
> (git and mingw-w64) set up such conditions where poll.c fails to compile.

Well, yes and no: gnulib is mostly a collection of compatibility
reimplementaions of functions that should be available on an ideal
system.

> If one wants to dig deeper, I'd say the problem is in MinGW-W64 headers
> because their behavior of hiding MsgWaitForMultipleObjects doesn't
> match behavior of MSVC headers.

Thank you very much for this analysis.
It enables us to redirect you the third time: to report this as a
bug in MinGW-W64 !  ;-)

Seriously, it looks you found the best description of the problem,
and it would be nice if you could modify your patch so that it
is really a work around: it would be in effect only for MinGW-W64,
and the comment would explain that this is a hack to work around the
bug.  

If you manage to change the defs for poll.c without changing its
content, no one could tell you to report to gnulib first.

OTOH, if MsgWaitForMultipleObjects is present ustream (in gnulib's
poll.c, sorry that I cannot check right now), it still might be
better to submit the work-around there first.

Thanks for your work,
	Stepan Kasal

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

[Felipe Contreras]

Marat Radchenko wrote:
> If one wants to dig deeper, I'd say the problem is in MinGW-W64
> headers because their behavior of hiding MsgWaitForMultipleObjects
> doesn't match behavior of MSVC headers.

I agree with that. Can you file a bug report?

-- 
Felipe Contreras

Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

[Marat Radchenko]

On Sun, May 04, 2014 at 08:52:44PM +0200, Stepan Kasal wrote:
> Thank you very much for this analysis.
> It enables us to redirect you the third time: to report this as a
> bug in MinGW-W64 !  ;-)

I'll report this to MinGW-W64 soon, though even if/when they fix
the issue on their side, I'd still like to have a workaround in
Git to be able to use older MinGW-W64 versions that didn't
receive a fix.

> Seriously, it looks you found the best description of the problem,
> and it would be nice if you could modify your patch so that it
> is really a work around: it would be in effect only for MinGW-W64,
> and the comment would explain that this is a hack to work around the
> bug.  

Workarounds do not have to be ugly and full of #ifdef's.

> If you manage to change the defs for poll.c without changing its
> content, no one could tell you to report to gnulib first.

v1 does exactly this.

> OTOH, if MsgWaitForMultipleObjects is present ustream (in gnulib's
> poll.c, sorry that I cannot check right now), it still might be
> better to submit the work-around there first.

Workaround is "just don't pass -DNOGDI on MinGW-W64 if you want
MsgWaitForMultipleObjects", there's nothing to send to gnulib.
After all, was there a strong reason why Git started passing it?
What is there was no option to disable part of windows.h?

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

['502304919' via msysGit]

[-- Attachment #1: Type: text/plain, Size: 2498 bytes --]

I've added this to my to-do list. On May 4, 2014 at 3:55:52 PM CDT, Marat Radchenko <marat@slonopotamus.org> wrote:On Sun, May 04, 2014 at 08:52:44PM +0200, Stepan Kasal wrote:> Thank you very much for this analysis.> It enables us to redirect you the third time: to report this as a> bug in MinGW-W64 ! ;-)I'll report this to MinGW-W64 soon, though even if/when they fixthe issue on their side, I'd still like to have a workaround inGit to be able to use older MinGW-W64 versions that didn'treceive a fix.> Seriously, it looks you found the best description of the problem,> and it would be nice if you could modify your patch so that it> is really a work around: it would be in effect only for MinGW-W64,> and the comment would explain that this is a hack to work around the> bug. Workarounds do not have to be ugly and full of #ifdef's.> If you manage to change the defs for poll.c without changing its> content, no one could tell you to report to gnulib first.v1 does exactly this.> OTOH, if MsgWaitForMultipleObjects is present ustream (in gnulib's> poll.c, sorry that I cannot check right now), it still might be> better to submit the work-around there first.Workaround is "just don't pass -DNOGDI on MinGW-W64 if you wantMsgWaitForMultipleObjects", there's nothing to send to gnulib.After all, was there a strong reason why Git started passing it?What is there was no option to disable part of windows.h?--To unsubscribe from this list: send the line "unsubscribe git" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at http://vger.kernel.org/majordomo-info.html     

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 3300 bytes --]

Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

[Felipe Contreras]

Stepan Kasal wrote:
> diff --git a/config.mak.uname b/config.mak.uname
> index 82b8dff..446dd41 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -508,7 +508,11 @@ ifneq (,$(findstring MINGW,$(uname_S)))
>  	NO_POSIX_GOODIES = UnfortunatelyYes
>  	DEFAULT_HELP_FORMAT = html
>  	NO_D_INO_IN_DIRENT = YesPlease
> -	COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -D_USE_32BIT_TIME_T -DNOGDI -Icompat -Icompat/win32
> +	COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -D_USE_32BIT_TIME_T -Icompat -Icompat/win32
> +ifneq ($(uname_M),x86_64)
> +	# MinGW-W64 < x.y headers do not provide MsgWaitForMultipleObjects with NOGDI

MinGW-w64 != x86_64; it provides a i686 compiler as well.

-- 
Felipe Contreras

Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

[Stepan Kasal]

Hello,

On Mon, May 05, 2014 at 12:55:52AM +0400, Marat Radchenko wrote:
> On Sun, May 04, 2014 at 08:52:44PM +0200, Stepan Kasal wrote:
> > is really a work around: it would be in effect only for MinGW-W64,
> > and the comment would explain that this is a hack to work around the
> > bug.  
> 
> Workarounds do not have to be ugly and full of #ifdef's.

I'm afraid they have to.  If you just select one of the reasonable
variants, without noting that the other ones would trigger a bug, you
are lying a trap for future contributors.

> > If you manage to change the defs for poll.c without changing its
> > content, no one could tell you to report to gnulib first.
> 
> v1 does exactly this.

Yes, but it changes the define for other configurations as well
(MSVC, mingw 32bit).  I would suggest something along the change
below.

What do you think?

Stepan

diff --git a/config.mak.uname b/config.mak.uname
index 82b8dff..446dd41 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -508,7 +508,11 @@ ifneq (,$(findstring MINGW,$(uname_S)))
 	NO_POSIX_GOODIES = UnfortunatelyYes
 	DEFAULT_HELP_FORMAT = html
 	NO_D_INO_IN_DIRENT = YesPlease
-	COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -D_USE_32BIT_TIME_T -DNOGDI -Icompat -Icompat/win32
+	COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -D_USE_32BIT_TIME_T -Icompat -Icompat/win32
+ifneq ($(uname_M),x86_64)
+	# MinGW-W64 < x.y headers do not provide MsgWaitForMultipleObjects with NOGDI
+	COMPAT_CFLAGS += -DNOGDI
+endif
 	COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
 	COMPAT_OBJS += compat/mingw.o compat/winansi.o \
 		compat/win32/pthread.o compat/win32/syslog.o \
diff --git a/git-compat-util.h b/git-compat-util.h
index e6de32c..29a8afd 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -92,6 +92,9 @@
 #define WIN32_LEAN_AND_MEAN  /* stops windows.h including winsock.h */
 #include <winsock2.h>
 #include <windows.h>
+/* We cannot define NOGDI on MinGW-W64, so we unfortunately include
+   wingdi.h.  It then defines ERROR=0, undef it to avoid conflicts */
+#undef ERROR
 #define GIT_WINDOWS_NATIVE
 #endif
 

Re: [msysGit] Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI

[Stepan Kasal]

On Mon, May 05, 2014 at 02:32:11AM -0500, Felipe Contreras wrote:
> Stepan Kasal wrote:
> > +ifneq ($(uname_M),x86_64)
> > +	# MinGW-W64 < x.y headers do not provide MsgWaitForMultipleObjects with NOGDI
> 
> MinGW-w64 != x86_64; it provides a i686 compiler as well.

thanks for correcting me.  The diff was just a quick sketch.
Every workaround should say what bug is working around, otherwise it
is destined to become a superstition in the future.

Stepan