MSYS2 statically link output binary

Question

Is there any way to statically link the generated .exe file from MSYS2 gcc? I tried many ways, but none of them worked. All generated .exe files require msys-2.0.dll, which I want to get rid of. So far, I tried to enable -ststic option, -static-libgcc option and pass these options to -Wl, but non of them works. I tried to strip the binary or not, with no difference but the output file size. I know I can do this in MSYS1.0 gcc, or mingw-w64 from Linux, but I can not do this in MSYS2.0. After running gcc -v, it shows the tool chain was indeed compiled with --enable-static as well as --enable-shared and --enable-shared-libgcc. Is there anyway I can get static libgcc library?

Duer

Answer 1

Well, I solved it. From MSYS2's documents it says MSYS2 is designed to mitigate DLL hell and bugs by using a common, shared libc. Therefore, it is not intended to create statically linked executable.

However, you can install mingw-w64 package from pacman, and run mingw64.exe to launch the shell, instead of msys2.exe. By doing this, you can install and run original mingw-w64 compiler suite from bash, instead of the MSYS2 version.

The executable generated by original mingw-w64 package is statically linked. Instead of requiring msys-2.0.dll, it requires ubiquitously available msvcrt.dll.

Duer

Answer 2

I also had this problem - a very simple terminal program, utilizing only stdio.h and string.h, tended to raise "The code execution cannot proceed because msys-2.0.dll was not found. Reinstalling the program may fix this problem." in a normal terminal.

Finally, this post helped resolved the issue - but there were some subtle problems, which I'll note here.

Now, my problem was this:

I started by installing MSYS2; apparently I had installed GCC in it.

Now, even when I changed to the MINGW64 terminal (and not the MSYS2 terminal), and recompiled, I would have had the same problem with msys-2.0.dll.

Finally, I thought of checking in the MINGW64 terminal:

user@DESKTOP MINGW64 /c/
$ which gcc
/usr/bin/gcc

Note, that this - /usr/bin/gcc - is the exact same path, that you get back, if you're in the MSYS2 shell.

So, I tried to look for gcc again, in the MINGW64 shell:

$ pacman -Ss gcc
mingw32/mingw-w64-i686-gcc 7.4.0-1 (mingw-w64-i686-toolchain)
    GNU Compiler Collection (C,C++,OpenMP) for MinGW-w64
...
mingw64/mingw-w64-x86_64-gcc 8.2.1+20181214-1 (mingw-w64-x86_64-toolchain)
    GNU Compiler Collection (C,C++,OpenMP) for MinGW-w64
...
msys/gcc 7.4.0-1 (msys2-devel) [installed]
    The GNU Compiler Collection - C and C++ frontends
...

Aha, so it turns out I do not have the mingw64 gcc installed - I've only had the msys gcc installed!

So, just installed the mingw64 gcc - of course, from inside the MINGW64 (not the MSYS2) shell:

user@DESKTOP MINGW64 /c/
$ pacman -S mingw-w64-x86_64-gcc
resolving dependencies...
looking for conflicting packages...

Packages (7) mingw-w64-x86_64-binutils-2.30-5  mingw-w64-x86_64-crt-git-7.0.0.5302.6c8f5629-1
             mingw-w64-x86_64-headers-git-7.0.0.5302.6c8f5629-1  mingw-w64-x86_64-isl-0.19-1
             mingw-w64-x86_64-windows-default-manifest-6.4-3  mingw-w64-x86_64-winpthreads-git-7.0.0.5273.3e5acf5d-1
             mingw-w64-x86_64-gcc-8.2.1+20181214-1

Total Download Size:    51.55 MiB
Total Installed Size:  364.04 MiB

:: Proceed with installation? [Y/n] y
...

After this, you need to close and re-open the MINGW64 shell; once you do that, you can see that:

user@DESKTOP MINGW64 /c/
$ which gcc
/mingw64/bin/gcc

... now that path to gcc for MINGW64 is /mingw64/bin/gcc - while the path in MSYS2 remains /usr/bin/gcc.

Thus, if I now compile with gcc in MINGW64 shell, I compile with /mingw64/bin/gcc, and now my resulting .exe can run in the usual Windows command prompt, without asking for msys-2.0.dll - which is great :)

Enamour

Quick note to use pacman -S mingw-w64-i686-gcc, you need to restart as the MINGW32 shell – Apollonius