threads / patch / 50697

patchmingw: fix uname -r test

Subject: [PATCH 0/1] mingw: fix uname -r test

## tl;dr

4 messages between Mar 8, 2019 and Mar 11, 2019. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Johannes Schindelin via GitGitGadget· Mar 8, 2019, 15:51 UTC · lore

In df5218b4c30b (config.mak.uname: support MSys2, 2016-01-13), I obviously made the assumption that calling uname -r in MSYS2 would always yield a version number starting with "2".

That is incorrect, though, as uname -r reports the version of the Cygwin runtime on which the current MSYS2 runtime is based.

This sadly breaks our build as soon as we upgrade to an MSYS2 runtime that is based on Cygwin v3.0.2.

Happily, this patch fixes that.
Johannes Schindelin (1):
  mingw: allow building with an MSYS2 runtime v3.x
 config.mak.uname | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 6e0cc6776106079ed4efa0cc9abace4107657abf
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-160%2Fdscho%2Fmsys2-3.x-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-160/dscho/msys2-3.x-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/160
-- 
gitgitgadget
Johannes Schindelin via GitGitGadget· Mar 8, 2019, 15:51 UTC · re: Johannes Schindelin via GitGitGadget · lore

[PATCH 1/1] mingw: allow building with an MSYS2 runtime v3.x

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Recently the Git for Windows project started the upgrade process to a MSYS2 runtime version based on Cygwin v3.x.

This has the very notable consequence that `$(uname -r)` no longer reports a version starting with "2", but a version with "3".

That breaks our build, as df5218b4c30b (config.mak.uname: support MSys2, 2016-01-13) simply did not expect the version reported by `uname -r` to depend on the underlying Cygwin version: it expected the reported version to match the "2" in "MSYS2".

So let's invert that test case to test for *anything else* than a version starting with "1" (for MSys). That should safeguard us for the future, even if Cygwin ends up releasing versionsl like 314.272.65536.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 config.mak.uname | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to config.mak.uname +1 −1
diff --git a/config.mak.uname b/config.mak.uname
index c8b0e34c31..0207e895a4 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -569,7 +569,7 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
 	NO_GETTEXT = YesPlease
 	COMPAT_CLFAGS += -D__USE_MINGW_ACCESS
 else
-	ifeq ($(shell expr "$(uname_R)" : '2\.'),2)
+	ifneq ($(shell expr "$(uname_R)" : '1\.'),2)
 		# MSys2
 		prefix = /usr/
 		ifeq (MINGW32,$(MSYSTEM))
-- 
gitgitgadget
Junio C Hamano· Mar 10, 2019, 01:09 UTC · re: Johannes Schindelin via GitGitGadget · lore

Re: [PATCH 1/1] mingw: allow building with an MSYS2 runtime v3.x

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

> So let's invert that test case to test for *anything else* than a
> version starting with "1" (for MSys). That should safeguard us for the
> future, even if Cygwin ends up releasing versionsl like 314.272.65536.

An obvious alternative is to do "2" -> "[23]" *and* update the else to an explicit check for "1", *and* add an else that fails the build when it sees "4" and other unknown ones.

I do not know how compatible MSYS2 runtime v4.x will be with the settings the part inside the ifneq() we see here protects, but you probably do, so I think this would be good enough. The only case that makes any difference is when v4.x _mostly_ satisifies but slightly differs, affecting the built binary in a subtle way that is not discovered right away. But in such a case, the more cautious "fail on '4' that we do not recognize" will not help much, as the first reaction after seeing the error would be to copy the settings that used to be OK with v2.x and v3.x anyway (which is what is being done here---we start with the assumption that the support needed for v3.x is largely the same as v2.x).

Will queue directly on top of... 'maint'?  'master'?
Let's say 'maint' and merge that up to 'master'.
Thanks.
Show 19 quoted lines
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  config.mak.uname | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/config.mak.uname b/config.mak.uname
> index c8b0e34c31..0207e895a4 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -569,7 +569,7 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
>  	NO_GETTEXT = YesPlease
>  	COMPAT_CLFAGS += -D__USE_MINGW_ACCESS
>  else
> -	ifeq ($(shell expr "$(uname_R)" : '2\.'),2)
> +	ifneq ($(shell expr "$(uname_R)" : '1\.'),2)
>  		# MSys2
>  		prefix = /usr/
>  		ifeq (MINGW32,$(MSYSTEM))
Johannes Schindelin· Mar 11, 2019, 16:32 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/1] mingw: allow building with an MSYS2 runtime v3.x

Hi Junio,
On Sun, 10 Mar 2019, Junio C Hamano wrote:
Show 10 quoted lines
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > So let's invert that test case to test for *anything else* than a
> > version starting with "1" (for MSys). That should safeguard us for the
> > future, even if Cygwin ends up releasing versionsl like 314.272.65536.
> 
> An obvious alternative is to do "2" -> "[23]" *and* update the else to
> an explicit check for "1", *and* add an else that fails the build when
> it sees "4" and other unknown ones.
Right.
> I do not know how compatible MSYS2 runtime v4.x will be with the
> settings the part inside the ifneq() we see here protects, but you
> probably do, so I think this would be good enough.

I would expect Cygwin v4.x (which will be the basis for MSYS2 runtime v4.x) to be as diligent as Cygwin v3.x in maintaining as much backwards compatibility as possible.

Read: I trust "2 or higher" to be the answer.
Show 12 quoted lines
> The only case that makes any difference is when v4.x _mostly_ satisifies
> but slightly differs, affecting the built binary in a subtle way that is
> not discovered right away.  But in such a case, the more cautious "fail
> on '4' that we do not recognize" will not help much, as the first
> reaction after seeing the error would be to copy the settings that used
> to be OK with v2.x and v3.x anyway (which is what is being done
> here---we start with the assumption that the support needed for v3.x is
> largely the same as v2.x).
> 
> Will queue directly on top of... 'maint'?  'master'?
> 
> Let's say 'maint' and merge that up to 'master'.
Thank you.

For the record, the really super ugly hack I plan on implementing to make Windows builds pass in our Azure Pipeline is to build the git-sdk-64-minimal artifact (which contains all of the stuff needed to compile Git for Windows, such as `make`, `gcc`, etc) is to "install" a different `uname`: as the MINGW binaries live in `/mingw64/bin/` (unlike the MSYS binaries, which live in `/usr/bin/`, like `uname.exe`), I can write the following script into `/mingw64/bin/uname`:

	#!/bin/sh
	case "$*" in -r) echo 2.bogus;; *) /usr/bin/uname "$*";; esac

This will be the stop-gap solution for branches that are based on commits *without* this here patch.

It's ugly alright, but the only hack I could think of that actually will work.

Ciao, Dscho

Show 23 quoted lines
> 
> Thanks.
> 
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  config.mak.uname | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/config.mak.uname b/config.mak.uname
> > index c8b0e34c31..0207e895a4 100644
> > --- a/config.mak.uname
> > +++ b/config.mak.uname
> > @@ -569,7 +569,7 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
> >  	NO_GETTEXT = YesPlease
> >  	COMPAT_CLFAGS += -D__USE_MINGW_ACCESS
> >  else
> > -	ifeq ($(shell expr "$(uname_R)" : '2\.'),2)
> > +	ifneq ($(shell expr "$(uname_R)" : '1\.'),2)
> >  		# MSys2
> >  		prefix = /usr/
> >  		ifeq (MINGW32,$(MSYSTEM))
> 

← back to recent threads