Reuben Thomas wrote:
> I am not using MSYS2 per se, I am using the Mingw64 environment
There is no such thing as "the Mingw64 environment". Better be
careful about the terms.
We need to distinguish
* mingw - which is a toolchain (set of runtime libraries, together
with a customized GCC)
from
* the development environments that people use. There are at least
- Cygwin with installed mingw-* packages,
- MSYS2,
- Debian/Ubuntu with cross tools, using WINE as intermediate layer
for executing Windows binaries.
> i.e. the shell called "MSYS2 MinGW x64" in the MSYS2 64-bit set of shells.
That is the MSYS2 environment, and in particular with an augmented PATH
that contains tools for producing mingw binaries that are linked to
the Microsoft 'MSVCRT' runtime library.
Whereas the other one, that MSYS2 calls "UCRT64", is also the MSYS2
environment, but in particular with a different augmented PATH
that contains tools for producing mingw binaries that are linked to
the Microsoft 'ucrt' runtime library.
Both are MSYS2, and both contain the program-arguments-munging hack
that makes the whole environment unreliable.
> I do indeed seem to be in a mingw64 environment…specifically,
>
> $ echo $MSYSTEM
> MINGW64
No. The fact that the MSYSTEM environment variable is set is a witness
that you are in the MSYS2 environment.
> > AFAIU, MSYS_NO_PATHCONV=1 is the workaround for old (defunct) MSYS and
> > MSYS2_ARG_CONV_EXCL=* is the workaround for MSYS2. See
> > https://www.msys2.org/wiki/Porting/#filesystem-namespaces
>
> I had already read this, and it doesn't seem to correspond to the behaviour
> I find I get.
Oh. So even their documentation is not well up-to-date.
> I think the best action will be to document that the 'relocatable' modules
> > are not supported in MSYS2 as build environment.
>
> That would be good too
OK, then I'll do that...
Bruno
