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?
Static linking increases the file size of your program, and it may increase the code size in memory if other applications, or other copies of your application, are running on the system. This option forces the linker to place the library procedures your program references into the program's object file.
Static linking means that the code for all routines called by your program becomes part of the executable file. Statically linked programs can be moved to run on systems without the IBM Open XL C/C++ runtime libraries.
Static libraries are created by copying all necessary library modules used in a program into the final executable image. The linker links static libraries as a last step in the compilation process. An executable is created by resolving external references, combining the library routines with program code.
In computer science, a static library or statically-linked library is a set of routines, external functions and variables which are resolved in a caller at compile-time and copied into a target application by a compiler, linker, or binder, producing an object file and a stand-alone executable.
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 :)
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With