Open nickhutchinson opened 9 years ago
It's a heuristic, of course we can't know which things are paths and which aren't. Disabling it globally will get you a fairly useless MSYS2. In fact, you may as well use Cygwin in that case. But this isn't a reason not to provide this capability as there may be some extreme edge cases when such a blunt tool is useful.
In the meantime, many Windows executables can use either - or / as the first character of a switch/option.
I have a similar problem running cl
of ms build tools in mingw32-make
when I try to build fbalpha
, the error line shown is https://github.com/barry65536/FBAlpha/blob/416948158d88ba17f87813419ddc3c1209ef68c0/makefile.vc#L456. I printed the executed command, tried to run it in the cmd
directly and it was ok. So the problem maybe the execution shell is not cmd
but bash
in msys2
/mingw32
. I also add echo $$SHELL
in makefile which it printed /usr/bin/bash
.
I tried to executed cl /h
in mingw32 shell, /h
seemed interpreted different then cmd.
cl
command run in the cmd
shell:
I tried to executed cl /h in mingw32 shell
Why?
I tried to executed cl /h in mingw32 shell
Why?
Because the interpretation of cl /h
in cmd and mingw32 is quite different. /h
in mingw32 shell seemed expanded or modified. If /h
arguments passed as is, the make process would no problems.
Liu.D.H@DESKTOP-DELL MINGW32 /d/code/other/fbalpha
$ "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\Hostx86\x86\cl.exe" /h
Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31629 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9024 : unrecognized source file type 'H:/', object file assumed
Microsoft (R) Incremental Linker Version 14.33.31629.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:.exe
H:/
LINK : fatal error LNK1181: cannot open input file 'H:\.obj'
Liu.D.H@DESKTOP-DELL MINGW32 /d/code/other/fbalpha
D:\code\other\FBAlpha>"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\Hostx86\x86\cl.exe" /h
Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31629 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9002 : ignoring unknown option '/h'
cl : Command line error D8003 : missing source filename
D:\code\other\FBAlpha>
Maybe the commands in makefile should escape /
. But how to do it automatically?
Liu.D.H@DESKTOP-DELL MINGW32 /d/code/other/fbalpha
$ "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\Hostx86\x86\cl.exe" /h
Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31629 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9024 : unrecognized source file type 'H:/', object file assumed
Microsoft (R) Incremental Linker Version 14.33.31629.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:.exe
H:/
LINK : fatal error LNK1181: cannot open input file 'H:\.obj'
Liu.D.H@DESKTOP-DELL MINGW32 /d/code/other/fbalpha
$ "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\Hostx86\x86\cl.exe" //h
Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31629 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9002 : ignoring unknown option '/h'
cl : Command line error D8003 : missing source filename
Liu.D.H@DESKTOP-DELL MINGW32 /d/code/other/fbalpha
$
I'm finding MSYS2's automatic mangling of environment variables1 2 when running native Win32 applications to be quite problematic. For example, any environment variable whose value begins with a forward slash appears to be interpreted as a UNIX path and is rewritten to be prefixed with "c:/msys64" when accessed by a Win32 app.
Relying on heuristics like this seems really error prone, so I'd like to request the ability to disable this behaviour globally.
Steps to reproduce:
1: http://sourceforge.net/p/msys2/wiki/How%20does%20MSYS2%20differ%20from%20Cygwin/ 2: http://sourceforge.net/p/msys2/wiki/Porting/