GNU bug report logs - #75939
bug in compile wrapper when using MSVC from Msys2

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75939 in the body.
You can then email your comments to 75939 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kirill Makurin <maiddaisuki <at> outlook.com>
To: "bug-automake <at> gnu.org" <bug-automake <at> gnu.org>
Subject: bug in compile wrapper when using MSVC from Msys2
Date: Wed, 29 Jan 2025 23:09:40 +0000

[Message part 1 (text/plain, inline)]

Hi,

I would like to report one quite annoying issue related to Automake's `compile` wrapper when it is used with `cl.exe` to compile some C++ files from Msys2.

I was building some GNU packages with MSVC's `cl.exe`, and compilation of some C++ source files was failing with `cl.exe` reporting non-sensual filenames like `H:E:/Msys2/{builddir}/somefile.cxx`.

Apparently, the issue is double conversion of a unix-style filename by Msys2's shell. In example above, Msys2 is installed to `E:/Msys2` and builddir is `/h/{builddir}`.

As I figured out later, it was happening because `compile` was converting `/h/{builddir}/somefile.cxx` to `H:/{builddir}/somefile.cxx` and passing it as `-TpH:/{builddir}/somefile.cxx` to `cl.exe`. However, Msys2 was interpreting `/{builddir}/somefile.cxx` as a unix-style path and converted it again, resulting in `-TpH:E:/Msys2/{builddir}/somefile.cxx`.

One way to work around this issue is :

```
export MSYS2_ARG_CONV_EXCL='-Tp'
```

However, this must be set by the user, which is inconvenient. I wonder if anything can be done in the `compile` wrapper to fix this.

I am using latest versions of MSVC tools and `cl.exe` allows to pass argument to `-Tp` as a separate argument and this seems to work correctly. However, I don't know whether older versions of `cl.exe` allow it.

- Kirill Makurin

[Message part 2 (text/html, inline)]

Message #8 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: maiddaisuki <at> outlook.com
Cc: 75939 <at> debbugs.gnu.org
Subject: Re: bug#75939: bug in compile wrapper when using MSVC from Msys2
Date: Thu, 30 Jan 2025 16:52:17 -0700

Hi Kirill - thanks for the report and proposed fix.

    export MSYS2_ARG_CONV_EXCL='-Tp'

Setting an environment variable seems fairly safe, since if an older
version of the compiler doesn't pay attention to it, at least the
problem will not become worse.

However, I'd like to hear from others who use msys, cl, Windows, etc.
(Since I don't), as to whether setting this in the compile script would
cause any problems. Anyone? --thanks, karl.

Message #11 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: "Andrew W. Nosenko" <andrew.w.nosenko <at> gmail.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: maiddaisuki <at> outlook.com, 75939 <at> debbugs.gnu.org
Subject: Re: bug#75939: bug in compile wrapper when using MSVC from Msys2
Date: Fri, 31 Jan 2025 08:49:15 +0100

[Message part 1 (text/plain, inline)]

What if user set this variable for some reasons like additional extra
flags? So, it need to add flags to variable, not override it completely, at
least.

Sent from mobile


On Fri, 31 Jan 2025 at 00:53, Karl Berry <karl <at> freefriends.org> wrote:

> Hi Kirill - thanks for the report and proposed fix.
>
>     export MSYS2_ARG_CONV_EXCL='-Tp'
>
> Setting an environment variable seems fairly safe, since if an older
> version of the compiler doesn't pay attention to it, at least the
> problem will not become worse.
>
> However, I'd like to hear from others who use msys, cl, Windows, etc.
> (Since I don't), as to whether setting this in the compile script would
> cause any problems. Anyone? --thanks, karl.
>
>
>
>

[Message part 2 (text/html, inline)]

Message #14 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Kirill Makurin <maiddaisuki <at> outlook.com>
To: "75939 <at> debbugs.gnu.org" <75939 <at> debbugs.gnu.org>
Cc: Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#75939: bug in compile wrapper when using MSVC from Msys2
Date: Fri, 31 Jan 2025 09:25:55 +0000

[Message part 1 (text/plain, inline)]

Keep in mind that if this variable is appended to, each item must be separated by a semicolon. Something like this:

```
if test -n "${MSYS2_ARG_CONV_EXCL}"
then
      MSYS2_ARG_CONV_EXCL="${MSYS2_ARG_CONV_EXCL};-Tp"
else
      MSYS2_ARG_CONV_EXCL='-Tp'
fi
export MSYS2_ARG_CONV_EXCL
```

- Kirill Makurin


________________________________
From: Andrew W. Nosenko <andrew.w.nosenko <at> gmail.com>
Sent: Friday, January 31, 2025 4:49 PM
To: Karl Berry <karl <at> freefriends.org>
Cc: maiddaisuki <at> outlook.com <maiddaisuki <at> outlook.com>; 75939 <at> debbugs.gnu.org <75939 <at> debbugs.gnu.org>
Subject: Re: bug#75939: bug in compile wrapper when using MSVC from Msys2

What if user set this variable for some reasons like additional extra flags? So, it need to add flags to variable, not override it completely, at least.

Sent from mobile


On Fri, 31 Jan 2025 at 00:53, Karl Berry <karl <at> freefriends.org<mailto:karl <at> freefriends.org>> wrote:
Hi Kirill - thanks for the report and proposed fix.

    export MSYS2_ARG_CONV_EXCL='-Tp'

Setting an environment variable seems fairly safe, since if an older
version of the compiler doesn't pay attention to it, at least the
problem will not become worse.

However, I'd like to hear from others who use msys, cl, Windows, etc.
(Since I don't), as to whether setting this in the compile script would
cause any problems. Anyone? --thanks, karl.

[Message part 2 (text/html, inline)]

Message #17 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org
Cc: maiddaisuki <at> outlook.com, 75939 <at> debbugs.gnu.org,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: setting $MSYS2_ARG_CONV_EXCL in compile script?
Date: Sun, 02 Feb 2025 16:10:22 +0100

[Message part 1 (text/plain, inline)]

Karl Berry wrote:
> Kirill (cc'd) proposed setting the MSYS2_ARG_CONV_EXCL envvar in the
> compile script which comes from Automake, to avoid a double-conversion.
> See his report in the first msg here, and the final suggestion in the last:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75939
> 
> I don't know anything about this. I've never done any programming under
> Windows, or msys, cygwin, wine, or any other Unix emulator under Windows.
> 
> So I wanted to ask for advice before tinkering with something as basic
> as the compile script in this way. Especially since it currently does
> not set any environment variables.
> 
> So ... I'm hoping for feedback like "yeah sure", or "no, we should do
> xyz instead", or "the problem is actually abc", or something. Since no
> feedback was forthcoming on the automake list, I'm trying here.
> 
> And if we do apply it, then where? In this branch?
> 	cygwin/* | msys/*)
> 	  file=`cygpath -m "$file" || echo "$file"`
> 
> But I fear this will cause trouble on cygwin. But if we separate the
> branches, then it seems like other trouble could ensue. Setting it
> unconditionally in all cases seems unnecessarily global to me, though
> maybe that is the simplest.

Table of contents:
* Cygwin vs. MSYS2
* Nature of the MSYS2 problem
* General recommendation
* Specific proposal

* ========== Cygwin vs. MSYS2

MSYS2_ARG_CONV_EXCL is documented in
https://www.msys2.org/docs/filesystem-paths/#process-arguments
Quote:
  "When calling native executables from the context of [MSYS] then all the
   arguments that look like Unix paths will get auto converted to Windows."

Cygwin and MSYS2 both are development environments for native Windows
programs on Windows. Cygwin passes argv[] from the caller to the callee
unmodified; MSYS2 modifies it, at every program invocation, based on
heuristics.

On Cygwin, therefore, it is the programmer's responsibility to use
'cygpath -w' at the appropriate places. Fortunately, there is a Gnulib
macro, build-to-host.m4, that makes this easy.

* ========== Nature of the MSYS2 problem

The MSYS2 problem is that it's a horrible hack that is based on a
heuristic: all arguments that "look like Unix paths" are modified.

The user can set MSYS2_ARG_CONV_EXCL to avoid this from happening
in 1, 2, 3, or 10 places. But it will never be 100% correct.

* ========== General recommendation

My general advice is:
  1) Recommend Cygwin, not MSYS2. Like I do in
     <https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob_plain;f=INSTALL.windows;hb=HEAD>
  2) Reduce the effort for GNU package upstream maintainers, by
     requesting a reasonably complete patch, not a piecemeal patch here
     and a piecemeal patch there.

* ========== Specific proposal

As for every bug report, the first action is to analyze the failure.
Here, the relevant lines of code in the 'compile' script are:

 	cygwin/* | msys/*)
 	  file=`cygpath -m "$file" || echo "$file"`

This is in function func_file_conv, which is used to produce arguments
for invocation of 'cl' (which is a native Windows program).

As documented in <https://cygwin.com/cygwin-ug-net/cygpath.html>,
"cygpath -m" produces file names like C:/Users/foobar/filename .
Some native Windows programs accept this syntax, some don't.
Therefore it is generally better to use "cygpath -w", which
produces file names like C:\Users\foobar\filename .
The *only* situation I've ever seen where "cygpath -m" is required
is when the callee is a shell script (with 'echo') that invokes
a Java program. (Example: IBM Application Server.)
Since the compiler called by 'compile' never is of this type, it is
better to use "cygpath -w".

Find attached a proposed patch. Tested on Cygwin with MSVC. Will work on
MSYS2 with MSVC as well.

Bruno

[0001-compile-Improve-support-for-C-compilations-on-MSYS2.patch (text/x-patch, attachment)]

Message #20 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org, Karl Berry <karl <at> freefriends.org>
Cc: Kirill Makurin <maiddaisuki <at> outlook.com>, 75939 <at> debbugs.gnu.org
Subject: Re: setting $MSYS2_ARG_CONV_EXCL in compile script?
Date: Mon, 03 Feb 2025 06:38:52 +0100

[Message part 1 (text/plain, inline)]

Kirill Makurin wrote:
> I was going to just say that this patch is good and go ahead with it, but I decided to check it and turns out it fixes this issue only partially, but the patch itself is good.
> 
> Msys2 has multiple environments (see https://www.msys2.org/docs/environments/) and this patch works only for `MSYS`. For all other environments `uname` will report a string starting with `MINGW64` and `compile` will set `file_conv` variable to `mingw`. This, unfortunately, overlaps with mingw32 which does not have `cygpath`.
> 
> For `mingw` the filename is converted in `compile` as follows:
> 
> ```
> mingw/*)
>       file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
> ```
> 
> The resulting converted filename has forward slashes as with `cygpath -m` and suffers from the same double conversion issue.
> 
> In theory we could prepend `cygpath` invocation in this branch like this:
> 
> ```
> mingw/*)
>       file=`cygpath -w  "$file" 2>/dev/null || cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
> ```
> 
> However, compilation is still going to fail if there is no `cygpath` (also ,`cygpath` is not installed with Msys2 by default).
> 
> I think a better solution may be to add additional sed invocation in the pipe to convert forward slashes to backslashes.
> 
> I also was wondering if passing `mingw` as the second argument into `func_file_conv ` in this branch could help, but unfortunately `/filename` in resulting `-Tp/filename` is not converted by Msys2.
> 
> ```
> *.cc | *.CC | *.cxx | *.CXX | *.[cC]++)
>         func_file_conv "$1"
> ```
> 
> I hope I didn't cause too much confusion about `MSYS2_ARG_CONV_EXCL`, I was a bit in a hurry and probably didn't make it clear that I meant setting `MSYS2_ARG_CONV_EXCL` more like an external user-side workaround (e.g. I was setting it in my build script).
> 
> - Kirill Makurin

Thanks for testing.

> For all other environments `uname` will report a string starting with `MINGW64`
> and `compile` will set `file_conv` variable to `mingw`.

OK, so what you saying is the detection / distinction of environments
is not working. Which is quite plausible, since the original code was
written in 2010 (when MSYS2 did not exist) and Paul's patch from 2019-11-11
was apparently not well tested (Paul is not using Windows environments).

So, let's fix this environment distinction. This is better than applying
workarounds that will affect behaviour on the original MinGW.

Here are 3 proposed patches:

0001) This is a cleanup of Paul's patch from 2019-11-11. Since $file_conv
      can only have one of the three values 'mingw', 'cygwin', 'wine',
      it is pointless to test whether this value is 'msys'.

0002) This patch extends the distinction of environments. Since I don't
      have first-hand info about these environments, I asked the prior
      knowledge summarization engine. Results are attached. I trust these
      answers, because MinGW + MSYS is a topic that is widely discussed
      on the web.

0003) This patch is the same as already proposed: use backslashed filenames
      instead of forward-slashes ones (that MSYS2 would interpret a second
      time).

Kirill: Testing of this patch series in your environment (MSYS2 + MSVC)
        is welcome.

Bruno

[0001-compile-Simplify.patch (text/x-patch, attachment)]

[0002-compile-Distinguish-various-MinGW-MSYS-MSYS2-environ.patch (text/x-patch, attachment)]

[0003-compile-Improve-support-for-C-compilations-on-MSYS2.patch (text/x-patch, attachment)]

[mingw-msys-environments.odt (application/vnd.oasis.opendocument.text, attachment)]

Message #23 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Kirill Makurin <maiddaisuki <at> outlook.com>
To: "bug-gnulib <at> gnu.org" <bug-gnulib <at> gnu.org>, Bruno Haible <bruno <at> clisp.org>
Cc: "75939 <at> debbugs.gnu.org" <75939 <at> debbugs.gnu.org>,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: setting $MSYS2_ARG_CONV_EXCL in compile script?
Date: Mon, 3 Feb 2025 08:25:55 +0000

[Message part 1 (text/plain, inline)]

I applied patches and they work for Msys2.

I also tested it with (what I assume is) "Msys-based MinGW" (https://osdn.net/projects/mingw/) and it fails. Its `uname -s` reports `MINGW32_NT-6.2` and it has `MSYSTEM` set , and it lacks `cygpath`.

Should we even distinguish between "original MinGW" and "Msys-based MinGW"? I think they both lack `cygpath` and should be treated the same. I may not know something about "original MinGW" though.

The `/etc/msystem` file does not exist with this "Msys-based MinGW".

The `uname -r` method mentioned in the attached file seems outdated. Current Msys2's `uname-r` has `x86_64` suffix instead of `msys` in its output (regardless of environment).

---

I explicitly set `file_conv` to `mingw` in compile just for testing with this MinGW and there are no issues with double conversion.

- Kirill Makurin

________________________________
From: Bruno Haible <bruno <at> clisp.org>
Sent: Monday, February 3, 2025 2:38 PM
To: bug-gnulib <at> gnu.org <bug-gnulib <at> gnu.org>; Karl Berry <karl <at> freefriends.org>
Cc: Kirill Makurin <maiddaisuki <at> outlook.com>; 75939 <at> debbugs.gnu.org <75939 <at> debbugs.gnu.org>
Subject: Re: setting $MSYS2_ARG_CONV_EXCL in compile script?

Kirill Makurin wrote:
> I was going to just say that this patch is good and go ahead with it, but I decided to check it and turns out it fixes this issue only partially, but the patch itself is good.
>
> Msys2 has multiple environments (see https://www.msys2.org/docs/environments/) and this patch works only for `MSYS`. For all other environments `uname` will report a string starting with `MINGW64` and `compile` will set `file_conv` variable to `mingw`. This, unfortunately, overlaps with mingw32 which does not have `cygpath`.
>
> For `mingw` the filename is converted in `compile` as follows:
>
> ```
> mingw/*)
>       file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
> ```
>
> The resulting converted filename has forward slashes as with `cygpath -m` and suffers from the same double conversion issue.
>
> In theory we could prepend `cygpath` invocation in this branch like this:
>
> ```
> mingw/*)
>       file=`cygpath -w  "$file" 2>/dev/null || cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
> ```
>
> However, compilation is still going to fail if there is no `cygpath` (also ,`cygpath` is not installed with Msys2 by default).
>
> I think a better solution may be to add additional sed invocation in the pipe to convert forward slashes to backslashes.
>
> I also was wondering if passing `mingw` as the second argument into `func_file_conv ` in this branch could help, but unfortunately `/filename` in resulting `-Tp/filename` is not converted by Msys2.
>
> ```
> *.cc | *.CC | *.cxx | *.CXX | *.[cC]++)
>         func_file_conv "$1"
> ```
>
> I hope I didn't cause too much confusion about `MSYS2_ARG_CONV_EXCL`, I was a bit in a hurry and probably didn't make it clear that I meant setting `MSYS2_ARG_CONV_EXCL` more like an external user-side workaround (e.g. I was setting it in my build script).
>
> - Kirill Makurin

Thanks for testing.

> For all other environments `uname` will report a string starting with `MINGW64`
> and `compile` will set `file_conv` variable to `mingw`.

OK, so what you saying is the detection / distinction of environments
is not working. Which is quite plausible, since the original code was
written in 2010 (when MSYS2 did not exist) and Paul's patch from 2019-11-11
was apparently not well tested (Paul is not using Windows environments).

So, let's fix this environment distinction. This is better than applying
workarounds that will affect behaviour on the original MinGW.

Here are 3 proposed patches:

0001) This is a cleanup of Paul's patch from 2019-11-11. Since $file_conv
      can only have one of the three values 'mingw', 'cygwin', 'wine',
      it is pointless to test whether this value is 'msys'.

0002) This patch extends the distinction of environments. Since I don't
      have first-hand info about these environments, I asked the prior
      knowledge summarization engine. Results are attached. I trust these
      answers, because MinGW + MSYS is a topic that is widely discussed
      on the web.

0003) This patch is the same as already proposed: use backslashed filenames
      instead of forward-slashes ones (that MSYS2 would interpret a second
      time).

Kirill: Testing of this patch series in your environment (MSYS2 + MSVC)
        is welcome.

Bruno

[Message part 2 (text/html, inline)]

Message #26 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org, Kirill Makurin <maiddaisuki <at> outlook.com>
Cc: 75939 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: setting $MSYS2_ARG_CONV_EXCL in compile script?
Date: Mon, 03 Feb 2025 11:56:29 +0100

[Message part 1 (text/plain, inline)]

Kirill Makurin wrote:
> I applied patches and they work for Msys2.
> 
> I also tested it with (what I assume is) "Msys-based MinGW" (https://osdn.net/projects/mingw/) and it fails. Its `uname -s` reports `MINGW32_NT-6.2` and it has `MSYSTEM` set , and it lacks `cygpath`.
> ...
> I explicitly set `file_conv` to `mingw` in compile just for testing with this MinGW and there are no issues with double conversion.

Thanks for testing.

In the download area of https://osdn.net/projects/mingw/, I cannot see an
"Msys-based MinGW". Rather, the page says
  "This is the official download site for the latest packages originating
   from the MinGW.OSDN Project, (formerly the MinGW.org Project; however,
   that domain is no longer associated with this project)."

Maybe the mix between the original MinGW and MSYS occurred on your machine?

Anyway, here's an update of the patch series, that should make things work
also in this situation (regardless how it originated).

I wouldn't want to test for the presence of 'cygpath' _without_ also testing
$MSYSTEM, because that could malfunction for people who access the original
MinGW binaries through a Cygwin environment (which is another mix-up that
people might do).

Bruno

[0001-compile-Simplify.patch (text/x-patch, attachment)]

[0002-compile-Distinguish-various-MinGW-MSYS-MSYS2-environ.patch (text/x-patch, attachment)]

[0003-compile-Improve-support-for-C-compilations-on-MSYS2.patch (text/x-patch, attachment)]

Message #29 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Kirill Makurin <maiddaisuki <at> outlook.com>
To: "bug-gnulib <at> gnu.org" <bug-gnulib <at> gnu.org>, Bruno Haible <bruno <at> clisp.org>
Cc: "75939 <at> debbugs.gnu.org" <75939 <at> debbugs.gnu.org>,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?
Date: Mon, 3 Feb 2025 11:17:45 +0000

[Message part 1 (text/plain, inline)]

The installer from https://osdn.net/projects/mingw/ is the same as found in https://sourceforge.net/projects/mingw/ (except for possible difference in versions) and the Wikipedia article points to the former website (mingw.org website is no longer alive). This installer provides both `mingw-*` (gcc, binutils) and `msys-*` (bash, autotools, etc.) packages. I am using its `msys.bat` to start the shell.

I also would like to notice that mingw32 (MinGW) has not been updated for a few years as of now.
________________________________
From: bug-automake-bounces+maiddaisuki=outlook.com <at> gnu.org <bug-automake-bounces+maiddaisuki=outlook.com <at> gnu.org> on behalf of Bruno Haible via Bug reports for Automake <bug-automake <at> gnu.org>
Sent: Monday, February 3, 2025 7:56 PM
To: bug-gnulib <at> gnu.org <bug-gnulib <at> gnu.org>; Kirill Makurin <maiddaisuki <at> outlook.com>
Cc: 75939 <at> debbugs.gnu.org <75939 <at> debbugs.gnu.org>; Karl Berry <karl <at> freefriends.org>
Subject: bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

Kirill Makurin wrote:
> I applied patches and they work for Msys2.
>
> I also tested it with (what I assume is) "Msys-based MinGW" (https://osdn.net/projects/mingw/) and it fails. Its `uname -s` reports `MINGW32_NT-6.2` and it has `MSYSTEM` set , and it lacks `cygpath`.
> ...
> I explicitly set `file_conv` to `mingw` in compile just for testing with this MinGW and there are no issues with double conversion.

Thanks for testing.

In the download area of https://osdn.net/projects/mingw/, I cannot see an
"Msys-based MinGW". Rather, the page says
  "This is the official download site for the latest packages originating
   from the MinGW.OSDN Project, (formerly the MinGW.org Project; however,
   that domain is no longer associated with this project)."

Maybe the mix between the original MinGW and MSYS occurred on your machine?

Anyway, here's an update of the patch series, that should make things work
also in this situation (regardless how it originated).

I wouldn't want to test for the presence of 'cygpath' _without_ also testing
$MSYSTEM, because that could malfunction for people who access the original
MinGW binaries through a Cygwin environment (which is another mix-up that
people might do).

Bruno

[Message part 2 (text/html, inline)]

Message #32 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Kirill Makurin <maiddaisuki <at> outlook.com>
To: "bug-gnulib <at> gnu.org" <bug-gnulib <at> gnu.org>, Bruno Haible <bruno <at> clisp.org>
Cc: "75939 <at> debbugs.gnu.org" <75939 <at> debbugs.gnu.org>,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?
Date: Mon, 3 Feb 2025 11:57:04 +0000

[Message part 1 (text/plain, inline)]

I tested updated patches and they work for both Msys2 and *MinGW*. For completeness, I also tried using it from Cygwin and it works as expected.
________________________________
From: bug-automake-bounces+maiddaisuki=outlook.com <at> gnu.org <bug-automake-bounces+maiddaisuki=outlook.com <at> gnu.org> on behalf of Bruno Haible via Bug reports for Automake <bug-automake <at> gnu.org>
Sent: Monday, February 3, 2025 7:56 PM
To: bug-gnulib <at> gnu.org <bug-gnulib <at> gnu.org>; Kirill Makurin <maiddaisuki <at> outlook.com>
Cc: 75939 <at> debbugs.gnu.org <75939 <at> debbugs.gnu.org>; Karl Berry <karl <at> freefriends.org>
Subject: bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

Kirill Makurin wrote:
> I applied patches and they work for Msys2.
>
> I also tested it with (what I assume is) "Msys-based MinGW" (https://osdn.net/projects/mingw/) and it fails. Its `uname -s` reports `MINGW32_NT-6.2` and it has `MSYSTEM` set , and it lacks `cygpath`.
> ...
> I explicitly set `file_conv` to `mingw` in compile just for testing with this MinGW and there are no issues with double conversion.

Thanks for testing.

In the download area of https://osdn.net/projects/mingw/, I cannot see an
"Msys-based MinGW". Rather, the page says
  "This is the official download site for the latest packages originating
   from the MinGW.OSDN Project, (formerly the MinGW.org Project; however,
   that domain is no longer associated with this project)."

Maybe the mix between the original MinGW and MSYS occurred on your machine?

Anyway, here's an update of the patch series, that should make things work
also in this situation (regardless how it originated).

I wouldn't want to test for the presence of 'cygpath' _without_ also testing
$MSYSTEM, because that could malfunction for people who access the original
MinGW binaries through a Cygwin environment (which is another mix-up that
people might do).

Bruno

[Message part 2 (text/html, inline)]

Message #35 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org, Kirill Makurin <maiddaisuki <at> outlook.com>
Cc: 75939 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?
Date: Mon, 03 Feb 2025 13:22:18 +0100

Kirill Makurin wrote:
> The installer from https://osdn.net/projects/mingw/ is the same as
> found in https://sourceforge.net/projects/mingw/ (except for possible
> difference in versions) and the Wikipedia article points to the former
> website (mingw.org website is no longer alive). This installer provides
> both `mingw-*` (gcc, binutils) and `msys-*` (bash, autotools, etc.)
> packages. I am using its `msys.bat` to start the shell.

Ok, I see. So, the web site of the original MinGW at some point started
to distribute a mix between MinGW and MSYS. And in this case
  `uname -s` is MINGW*,
  $MSYSTEM is non-empty,
  cygpath is not present.

The proposed code will then branch into this statement:

              # Original MinGW environment.
              file_conv=mingw

> I tested updated patches and they work for both Msys2 and *MinGW*. For completeness, I also tried using it from Cygwin and it works as expected.

Thank you. Karl, the three patches from the preceding mail are ready
to commit.

Bruno

Message #38 received at 75939 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bruno <at> clisp.org, maiddaisuki <at> outlook.com, 75939 <at> debbugs.gnu.org
Subject: Re: bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?
Date: Mon, 3 Feb 2025 23:20:02 +0100

    the three patches from the preceding mail are ready to commit.

Thanks very much for all your work (and explanations) on this, Bruno.
Committed. -k

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.