Fix incorrectly reported CPU in 32-bit Windows

We cannot rely on uname -m in Git for Windows' SDK to tell us what architecture we are compiling for, as we can compile both 32-bit and 64-bit git.exe from a 64-bit SDK, but the uname -m in that SDK will always report x86_64.

So let's go back to our original design. And make it explicitly Windows-specific.

Signed-off-by Johannes Schindelin <[email protected]>

---

compat/mingw.h +18 -0

@@ -6,6 +6,25 @@ typedef _sigset_t sigset_t;
+#ifdef __MINGW64_VERSION_MAJOR
+/*
+ * In Git for Windows, we cannot rely on `uname -m` to report the correct
+ * architecture: /usr/bin/uname.exe will report the architecture with which the
+ * current MSYS2 runtime was built, not the architecture for which we are
+ * currently compiling (both 32-bit and 64-bit `git.exe` is built in the 64-bit
+ * Git for Windows SDK).
+ */
+#undef GIT_HOST_CPU
+/* This was figured out by looking at `cpp -dM </dev/null`'s output */
+#if defined(__x86_64__)
+#define GIT_HOST_CPU "x86_64"
+#elif defined(__i686__)
+#define GIT_HOST_CPU "i686"
+#else
+#error "Unknown architecture"
+#endif
+#endif

Quoted 7 lines · Johannes Schindelin via GitGitGadget

We cannot rely on uname -m in Git for Windows' SDK to tell us what architecture we are compiling for, as we can compile both 32-bit and 64-bit git.exe from a 64-bit SDK, but the uname -m in that SDK will always report x86_64.

So let's go back to our original design. And make it explicitly Windows-specific.

b22894049f (version --build-options: also report host CPU, 2017-12-15) took this sort of case into consideration by introducing Makefile variable HOST_CPU (which takes precedence over uname -m), with the intention that, when cross-compiling, your build environment should (somehow) set HOST_CPU to the canonical name of the CPU on which the built Git will run (for instance, "x86_64" or "i686"). It would be nice to employ this mechanism to solve this issue rather than (re-)introducing a manually-maintained list of CPU names.

Can you say a few words (here in the email thread) about how the Git for Windows SDK is instructed to build for one architecture or the other?

With such information, perhaps we can figure out how to get the build environment itself to set HOST_CPU automatically so we don't have to resort to and worry about maintenance costs of a hard-coded CPU name list.

Quoted 22 lines

Signed-off-by Johannes Schindelin <[email protected]>

---

compat/mingw.h +18 -0

@@ -6,6 +6,25 @@ typedef _sigset_t sigset_t;
+#ifdef __MINGW64_VERSION_MAJOR
+/*
+ * In Git for Windows, we cannot rely on `uname -m` to report the correct
+ * architecture: /usr/bin/uname.exe will report the architecture with which the
+ * current MSYS2 runtime was built, not the architecture for which we are
+ * currently compiling (both 32-bit and 64-bit `git.exe` is built in the 64-bit
+ * Git for Windows SDK).
+ */
+#undef GIT_HOST_CPU
+/* This was figured out by looking at `cpp -dM </dev/null`'s output */
+#if defined(__x86_64__)
+#define GIT_HOST_CPU "x86_64"
+#elif defined(__i686__)
+#define GIT_HOST_CPU "i686"
+#else
+#error "Unknown architecture"
+#endif
+#endif

This is yet another patch I forgot to upstream, and I hope that it will make it into v2.21.0-rc1.

"Johannes Schindelin via GitGitGadget" <[email protected]>

Quoted 2 lines · writes:

This is yet another patch I forgot to upstream, and I hope that it will make it into v2.21.0-rc1.

I guess this affects nobody other than you and perhaps J6t, the point not being "there are only just two" but being "all of them know how to deal with possible breakages if any in this change".

I am tempted to bypass the usual "from pu down to next down to master" dance on this one, because of that.

;-)