MinGW-w64-Win32 Shell is wrongly compiling with msys-2.0.dll dependency

[veganaiZe]

When I compile a program with gcc in the Win32 Shell of MSYS2 it complains about missing msys-2.0.dll when attempting to run it as a stand-alone Windows (command-line) application.

Here is what my mingw32_shell.bat file looks like:

:
@echo off

rem ember value of GOTO: is used to know recursion has happened.
if "%1" == "GOTO:" goto %2

if NOT "x%WD%" == "x" set WD=

rem ember command.com only uses the first eight characters of the label.
goto _WindowsNT

start /min %COMSPEC% /e:4096 /c %0 GOTO: _Resume %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
goto EOF

rem ember that we execute here if we recursed.
:_Resume
for %%F in (1 2 3) do shift
if NOT EXIST %WD%msys-2.0.dll set WD=.\usr\bin\

rem ember that we get here even in command.com.
:_WindowsNT

if NOT EXIST %WD%msys-2.0.dll set WD=%~dp0usr\bin\

set MSYSTEM=MINGW32
rem To activate windows native symlinks uncomment next line
rem set MSYS=winsymlinks:nativestrict
rem Set debugging program for errors
rem set MSYS=error_start:%WD%../../mingw32/bin/qtcreator.exe^|-debug^|^<process-id^>
set MSYSCON=mintty.exe
if "x%1" == "x-consolez" set MSYSCON=console.exe
if "x%1" == "x-mintty" set MSYSCON=mintty.exe

if "x%MSYSCON%" == "xmintty.exe" goto startmintty
if "x%MSYSCON%" == "xconsole.exe" goto startconsolez

:startmintty
if NOT EXIST %WD%mintty.exe goto startsh
start %WD%mintty -i /msys2.ico /usr/bin/bash --login %*
exit

:startconsolez
cd %WD%..\lib\ConsoleZ
start console -t "MinGW" -r "%*"
exit

:startsh
start %WD%sh --login -i %*
exit

:EOF

Here is what gcc -v output looks like (from inside Win32 Shell console):

Using built-in specs.
COLLECT_GCC=C:\msys64\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-5.2.0/configure --prefix=/mingw32 --with-local-prefix=/mingw32/local --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --with-native-system-header-dir=/mingw32/i686-w64-mingw32/include --libexecdir=/mingw32/lib --with-gxx-include-dir=/mingw32/include/c++/5.2.0 --enable-bootstrap --with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev4, Built by MSYS2 project' --with-bugurl=http://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
gcc version 5.2.0 (Rev4, Built by MSYS2 project)

And uname -a output:

MINGW32_NT-6.3 myComputer 2.4.0(0.292/5/3) 2015-11-23 08:33 x86_64 Msys

[Ray Donnelly]

Please provide a http://sscce.org/

[veganaiZe]

Thank you for the response. Any hello world snippet would work fine; It was my use of cc instead of gcc. It turns out that when the C compiler is invoked as cc, it incorrectly targets x86_64-pc-msys. When invoked as gcc, it correctly targets i686-w64-mingw32.

So it seems as though the CC env var (for Win32/mingw32 shell) is improperly set, at some point. What should it be?

Thanks again.

BTW: My "CC" var looks like it's blank:

$ which cc
/usr/bin/cc

$ which gcc
/mingw32/bin/gcc

[David Macek]

Good catch. This one stabbed me once some time ago as well. You can set CC=gcc, that should work.

Ray, Alexey, should we solve this in /etc/profile, or make another symlink in the mingw-w64-gcc package?

[Ray Donnelly]

Yeah, or maybe figure out the specific location in the build scripts that causes msys2/gcc to end up with a cc and mingw{32,64}/mingw-w64-gcc not to and try to see if there's and logical explanation for the difference and re-evaluate from there?

But in the meantime, as a quick hack, I'd be happy with a commit that either adds cc to the mingw-w64-gcc packages or one that removes cc from the msys2 gcc packages.

[veganaiZe]

Just wanted to make sure that it is known that the CC env variable for the Mingw32/Win32 shell is blank and that it seems to fallback to /usr/bin/cc , somehow.

Thank you for taking care of this. MSYS2 is a very elegant fork of an otherwise half-baked solution (the original msys) and there is no alternative, in my opinion.

Chris

[David Macek]

New packages with /mingwXX/bin/cc.exe are uploaded.