Compile C++ Windows exe standalone files with MSYS2 - c++

I've recently started using Msys2 to install gcc compiler to make some exe for Windows. It works very well, but there's a problem when passing my exe to my brother. His laptop has not msys2 installed and when he tries to run my exe some errors occur. Seems like few dll files are necessary to use my exe (like msys-2.0.dll).
I've found out that those files are used by msys2 to "fake" the OS on the machine pretending it's a POSIX one. Is there a way to compile standalone exe for windows with msys2? I would like my brother to be able to use my exe without installing msys or else.
Here are all the details to understand better my situation:
g++ HelloWord.cpp -o Helloword is the line I use to compile
C:\msys64\mingw64\bin here's the path where g++ is stored
All the exact error messages I receive from windows after double clicking on the exe file that has been generated. Note that these messages do not appear on the CMD, but in a classic Windows error pop-up:
The program can't start because msys-2.0.dll is missing from your computer.
Try reinstalling the program to fix this problem.
The program can't start because libstdc++-6.dll is missing from your computer.
Try reinstalling the program to fix this problem.
The program can't start because libgcc_s_seh-1.dll is missing from your computer.
Try reinstalling the program to fix this problem.
Fixed:
I've resolved the issue just using the g++ parameter -static. Is it an overkill?

My version of MinGW is a bit old ...
C:\example>where g++
C:\misc\mingw810_64\bin\g++.exe
C:\example>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
But same idea:
C:\example>cat > compile_me.cpp
#include <iostream>
int main () { std::cout << "hi" << std::endl; }
^Z
C:\example>g++ compile_me.cpp -o compiled.exe
C:\example>compiled.exe
hi
C:\example>dumpbin /dependents compiled.exe
...
Image has the following dependencies:
KERNEL32.dll
msvcrt.dll
libstdc++-6.dll
...
In that case (dynamically linked stdlib) you'd deploy libstdc++6.dll with the executable, installing it to the same path as the exe (the other two are generally present in the windows system path).
If you want to drop that dependency, use -static:
C:\example>g++ compile_me.cpp -o compiled.exe -static
C:\example>compiled.exe
hi
C:\example>dumpbin /dependents compiled.exe
...
Image has the following dependencies:
KERNEL32.dll
msvcrt.dll
...
Deploying that .exe alone should be fine.
The file size will be larger but that's not a huge deal these days. Also your MinGW / MSYS install might come with strip:
C:\example>dir compiled.exe
Volume in drive C is Windows
Volume Serial Number is D2BA-C6F0
Directory of C:\example
09/24/2022 06:49 PM 2,389,120 compiled.exe
1 File(s) 2,389,120 bytes
0 Dir(s) 135,945,314,304 bytes free
C:\example>strip compiled.exe
C:\example>dir compiled.exe
Volume in drive C is Windows
Volume Serial Number is D2BA-C6F0
Directory of C:\example
09/24/2022 07:03 PM 838,656 compiled.exe
1 File(s) 838,656 bytes
0 Dir(s) 135,944,765,440 bytes free
C:\example>compiled.exe
hi
If there are other dynamic libraries that your particular executable ends up depending on, and the vendor has chosen not to provide statically linked alternatives, then you'll have to just deploy them with the exe. It's generally easy enough to just throw everything in a zip file or use your favorite scriptable installer.
(Note: dumpbin ships with Visual Studio; and can be found in some appropriate subdirectory in VC\Tools in the vs install path).

MSYS2 compiles native PE32 executables. It does not rely on any magic msys environment or static linking.
Get yourself a dependency walker and look to see what DLLs your app needs to run. Anything not in a Windows subdirectory should be where you focus your attention. Also make sure your app does not require any special Microsoft redistributable dependencies.
Ultimately, you should be creating an installer for your application to handle dependencies. I personally like Inno setup, but plenty of others exist that are well liked also.

The OP has solved their problem but for anyone else who finds this:
Make sure you launch MSYS2 by clicking on mingw64.exe or the equivalent shortcut.
Run which g++ to make sure you are using /mingw64/bin/g++. If it shows some other g++ then run pacman -S mingw-w64-x86_64-toolchain to install the toolchain.
Compile your code with g++ and use the -static option.
Run ntldd yourprogram.exe to check which DLLs your program is using and make sure they are part of Windows, not part of MSYS2.

Related

cc1.exe System Error - libwinpthread-1.dll missing - But it isn't

I recently downloaded MinGW-w64 from Sourceforge onto my external hard drive, where all the files reside in:
E:\mingw-w64\x86_64-4.9.2-posix-seh-rt_v3-rev1\mingw64\bin
When I try compiling my first "Hello World" program using gcc on Windows 8.1, I get a cc1.exe System Error, that tells me
The program can't start because libwinpthread-1.dll is missing.
Try reinstalling the program to fix the problem.
And yet, libwinpthread-1.dll (all 54,784 bytes of it) is sitting right there in the very same directory as gcc.exe. Do I really need to reinstall everything, or is something else going wrong here?
I know this post is over two years old but I recently had the same problem when using CMake.
I fixed it by adding MinGW to the "Path" Envionment Variable:
I am using Windows 10 Home.
"Windows Key"+ Pause/Break
On the left there is "Advanced System settings"
On the bottom of this window there is a button called "Environment Variables"
Click on the name "Path"
Click on "edit" under System Variables
Add your MinGW directory there. For me that was C:\MinGW\bin
I Hope I could help. If not you, maybe someone else.
I consider it best to statically link the libraries needed. This means that the executable can be run anywhere, without having to look for them. To do this, use the -static flag in the linker.
For example:
g++.exe -o ......\bin\connect.exe obj\Release\src\connect.o -static
You can follow this.
In codeblocks go to settings > compiler and mark these i have shown in picture
Hope it will work.
If you're missing libwinpthread-1.dll it means you're missing the entire MinGW toolchain and you'll have many more problems with other DLLs. Instead of adding this single DLL, install the entire MinGW toolchain to avoid further issues.
Install MSYS2 x64
Open MSYS2 MinGW x64 command prompt
Run pacman -S base-devel mingw-w64-x86_64-toolchain to install the GCC toolchain (all components)
Add c:\msys64\mingw64\bin to the System PATH
I've used following to fix:
pacman -Fsy "libwinpthread-1.dll"
pacman -S mingw64/mingw-w64-x86_64-libwinpthread-git
the dll files are already in the application file but what you need to do is copy the dll files and paste it in windows system32

Netbeans and MinGW-w64

I'm trying to configure my NetBeans on win7 64bit, to work with the MinGW-w64.
So I put in the %PATH% variable the following paths of the compiler:
C:\mingw-w64-bin_i686\mingw\bin
C:\minGw-MSYS\msys\bin
C:\mingw-w64-bin_i686\libexec\gcc\x86_64-w64-mingw32\4.7.0
Then I opened NetBeans and this was configured:
The configuration in NetBeans
I tried to compile a little test program but I received this error:
g++.exe: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not
found compilation terminated. make[2]: *
[dist/Debug/MinGW-Windows/test.exe] Error 1 make1: [.build-conf]
Error 2 make: ** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 1s)
I do have this file in C:\mingw-w64-bin_i686\libexec\gcc\x86_64-w64-mingw32\4.7.0
what am I missing?
Right, after months of putting this off I've finally sat down and done it. I'll probably make a more detailed post on my blog with pretty pictures but here is a trimmed down SO version which will hopefully be enough for you (and everyone else) to get going with.
Prerequisites
Remove MinGW, MSYS and CMake if you have them and can afford to lose them (we will reinstall MinGW (obv.) and MSYS but not CMake as it doesn't appear to be needed.)
Netbeans or other suitable IDE
64bit Windows.
EnvMan (optional but handy for managing Windows Environment
variables.)
Installation
MinGW-W64 C compiler and MSYS
Download and install MinGW-W64
http://mingw-w64.sourceforge.net/ (link is on the left menu with a
hyperlink called 'WIN64 Downloads'.)
There are a lot of versions which can be a bit complicated. We are
going with mingw-w64-bin_i686-mingw_20111220 (although the numbers at
the end may be different) which basically says we want the version
with the windows binaries.
Once the download is complete (about 300mb so 10min or so) extract to
C:\MinGW-W64 or similar. Make sure there aren't any spaces in the
path!
Download MSYS for MinGW-W64
Took a bit of searching
http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS is the wiki for
it and
http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/
is where I found the download and the version I went with was
MSYS-20111123
Once the download is complete extract the files to C:\MSys or
similar. Make sure there aren't any spaces in the path!
Setup
Add 'C:\MinGW-W64\bin' to your Windows PATH variable.
Add 'C:\MSys\msys\bin' to your Windows PATH variable.
Start Netbeans and go to Tools -> Options -> C/C++.
Click 'Add' under 'Tool Collection' and select the base directory of
MinGW-W64 (C:\MinGW-W64\bin).
Select 'MinGW' from 'Tool Collection Family' if it isn't
auto-detected and click 'OK'.
Set the 'C Compiler to C:\MinGW-W64\bin\x86_64-w64-mingw32-gcc.exe.
Set the 'C++ Compiler to C:\MinGW-W64\bin\x86_64-w64-mingw32-g++.exe.
Set the 'Make Command' to C:\MSys\msys\bin\make.exe.
And that should be it!
I should note that I am using the system to compile a library file to be use via JNI so have some additional steps for that which I missed out as they weren't needed here. However I made a quick 'Hello World' program and it compiled and ran nicely.
Happy coding!
I have just downloaded the latest automated build, unzipped it, added the main bin directory to path, and run:
x86_64-w64-mingw32-gcc test.cpp -o test.exe
and
x86_64-w64-mingw32-gcc -fuse-linker-plugin test.cpp -o test.exe
and it works. The same for the i686 variant. Your IDE is doing something wrong. Or you shouldn't have messed with the files. Or you shouldn't have removed the prefixes. Seriously.
PS: You only have to add the main "bin" directory to PATH, all the rest is wrong.
With some searching via your favorite Internet search engine, I have come across a better approach to quickly add MinGW-x64 to a Windows 64-bit system. On the Sourceforge site is MSYS2.
While following the installation directions and obtaining the most up to date packages, there may be a time out at the primary mirror site on Sourceforge. If so, follow the mirror site update directions and update the three pacman text files in the respective MSYS2 directory (e.g. /etc/pacman.d). Then proceed to complete the package updates from the MSYS2 installation directions.
Within the MSYS2 packages are things like gcc, llvm, make, dmake, etc. Here is the command used from the MSYS2 command line shell (e.g. bash) to install the GNU make utility:
$ pacman -S msys/make
The executable location it will be placed is: /usr/bin inside the MSYS2 command shell. As far as configuring Netbeans for where make.exe is located, the Windows path is:
MSYS2 installation directory\usr\bin\make.exe
(e.g. C:\msys64\usr\bin\make.exe).
To successfully build C++ with Netbeans, I used the GNU make package (e.g. msys/make). Then in order to use the default make files that Netbeans manages, and to not interfere with other C++ compilers within your Windows installation (e.g. Visual Studio, Intel, CLang from Visual Studio, etc.), run Netbeans from the MinGW-x64 command shell provided by MSYS2. In this way, the environment variables and other things like:
ls rm mkdir
will indicate successful execution and compilation within the Netbeans internal terminal window. I opened the MinGW-w64 Win64 Shell by navigating to the installed shortcut from MSYS2's installation. Then pasted into the MinGW-x64 shell command line, the Target property value from the Netbeans Windows desktop shortcut:
$ "C:\Program Files (x86)\NetBeans 7.4\bin\netbeans.exe"
And then could finally create the respective debug and release object and executable files. I also modified the Netbeans project output to be within the MSYS2 directory structure. Then run the executable within the MSYS2 MinGW-x64 shell. Running from the Netbeans IDE produces this error message:
Unable to start pty process: The application failed with exit code
-1073741515 (0xc0000135).
If the MSYS2 path were in the computer system's PATH environment variable, then perhaps this error would not happen.

Eclipse CDT error: Unable to compile

I tried to run a simple Hello world program. I am getting this error when I try to build it. What does it mean and how do I resolve it? I am using Windows 7 and I have MinGW and MSys in the %PATH%.
**** Build of configuration Debug for project learn ****
**** Internal Builder is used for build ****
g++ -IC:\MinGW\lib\gcc\mingw32\4.5.2\include\c++ -IC:\MinGW\libexec\gcc\mingw32\4.5.2 -O0 -g3 -Wall -c -fmessage-length=0 -osrc\learn.o ..\src\learn.cpp
g++: CreateProcess: No such file or directory
Build error occurred, build is stopped
Time consumed: 78 ms.
Code:
#include <iostream>
int main()
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
My %PATH% is:
C:\Users\Hari>echo %PATH%
C:\Program Files (x86)\MiKTeX 2.8\miktex\bin;C:\sml\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\WIDCOMM\Bluetooth Software\;C:\Program Files\WIDCOMM\Bluetooth Software\syswow64;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared\;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\Program Files (x86)\QuickTime\QTSystem\;G:\svn\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\SlikSvn\bin\;C:\cygwin\bin\;C:\Program Files\apache-maven-2.2.1\bin\;C:\PsTools;C:\MinGW\msys\1.0\bin;C:\MinGW\bin
I am able to run g++ from cmd:
C:\Users\Hari>g++ --version
g++ (GCC) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I found the same problem with a C HelloWorld invoking the MinGW gcc compiler. After quite a bit of experimentation, I have found that the MinGW binutils package is to blame! The latest one doesn't play nice with CDT for some reason. Use this one instead and it will work :)
binutils-2.21-2-mingw32-bin.tar.lzma
NOTE: versions 2.21-3 and later seem to have the problem.
Additionally, the latest GDB 7.3 seems to hang too. Use this one:
gdb-7.2-1-mingw32-bin.tar.lzma
Happy coding :)
PS: I don't even have MinGW or MSYS in the path. As long as MinGW is in C:\MinGW things seem to magically work.
Try rebooting your system after setting your environment. Please refer to here:
CreateProcess: No such file or directory
How did you create the project? Start with the New->C++ Project. Then under Executable pick the "Hello World C++ Project". On the Toolchains I pick the MinGW GCC toolchain but it's possible you don't have that installed. At any rate this creats a fully compilable executable that makes a good starting point for learning. It puts all the include directories, library paths etc in the project settings.
I had similiar problem.
Just deleted "C:\MinGW\bin" from the PATH, reinstalled MinGW and it worked. Ecllipse or CLion don't need PATH to be set. CLion even warns that "C:\MinGW\bin" should not be in the PATH.
I used an artifice.
I have installed the Dev-Cpp and within it comes installed Mingw32.
I copied the Mingw32 to directory c: and rename the mingw32 to c:\MinGW
and include to %PATH%. It worked very well.

C++ linking to python 3.2 x64 application unable to load

This is I guess a question in a few parts.
I'm working through the documentation on embedding the python interpreter. I've got everything compiling and linking wonderfully, only the application crashes when I run it ( to be specific its unable to load, so it hasn't even begun running).
I'm running windows 7 professional 64 bit. I'm compiling on the most recent nightly build of mingw, with msys ( which was packaged with the installer so no compatibility mismatch there I believe). The same code compiles fine on Ubuntu 10.10 using the default repository python 3.1 and build-essential tools.
So far in my research I'm believing this "might" be an issue between linking a 32 bit application ( as mingw is using 32 bit to my knowledge) with a 64 bit library (the python dll).
I can post code in full, however since this tends to be a linking/running issue I've only included the makefile to begin with. From the makefile below, I have copied the Python3.dll from C:\Python32\DLLs into the directory of my project. Also of note, that I had to create my own .def and then .a from the DLL in order to link ( symbols not found otherwise). Could this be a source of my issues?
Upon running a.exe (from both command line and explorer) I receive a standard alert window with:
Application Error: The application was unable to start correctly (0xc000007b). Click OK to close the application.
Correct me if I'm wrong, but this indicates that my executable is in some way corrupted.
I have tested my compiler/linker to ensure that it isn't a compiler/linker issue. It includes and this does NOT throw any errors on compiling, linking or running when the application does not use python.
Thanks for any assistance or light you can shed on the matter. This has me truly stumped.
pcnerd
Makefile
FILE= main.cpp
LIBS= -lpython3
LIBPATH= -L/c/python32/libs
INCLUDEPATH = -I/c/python32/include
CPP=g++
FLAGS = -g
build:
$(CPP) $(FLAGS) $(FILE) $(LIBS) $(LIBPATH) $(INCLUDEPATH)
If the python3.dll is definitely 64bit and your application is definitely 32bit, then this will not work. You can't link to 64bit dlls from 32bit applications. Pointers just won't be able to work between the two models.
You can't mix 32 and 64 bit images in the same process. End. Of. Story.

Adding gdb to MinGW

I've gone to http://sourceforge.net/project/showfiles.php?group_id=2435, downloaded the Automated MinGW Installer for MinGW 5.1.4 and at the same time the GNU Source-Level Debugger Release Candidate: GDB 6.8-3. I've then installed MinGW base tools into C:\MinGW. No problem so far.
However when I come to install the gdb debugger it has a lot of files and folders with the same names as some already installed but the files are different to those already installed. e.g C:\MinGW\include\bfd.h is 171 KB but gdb-6.8-mingw-3\include\bfd.h is 184 KB.
How do I add gdb to MinGW without breaking what's already installed?
In a command prompt I browsed to C:\MinGW\bin and ran:
mingw-get.exe install gdb
That fixed it for me. Not sure if it matters but I have C:\MinGW\bin in my path (guess I probably didn't need to browse to C:\MinGW\bin).
The Current Release (5.2.1) version of gdb at the project files page has always worked for me. The download is a stand-alone .exe, you don't need anything else.
But I'll bet the .exe in the 6.8 package will work, too. I'd try using just the .exe, and then if there are problems, try extracting the other files from the 6.8 package. (Though that may cause problems with the rest of the MinGW installation.)
Update: There seems to be a 7.something version. I haven't tested it thoroughly, but it seems to work, even with gcc 3.
Get Wascana Desktop Developer. It combines MinGW, gcc, Eclipse and gdb in one package.
You can safely overwrite the files prepackaged with MinGW with the (newer) ones from the gdb tarball. You can also choose not to overwrite them - just make sure to pick either one set, i.e. avoid mixing files from the older and the newer package.
Most of the offending files are probably not really relevant to you anyway. For example, the files belonging to the libbfd library aren't required for gdb's day to day operation, they're used if you want to extend the debugger or write debugging tools yourself.
At any rate, make a backup of the mingw directory before untarring the new release. It's very easy since MinGW is self-contained in that directory. That way, if anything should malfunction, you can just delete the directory and restore from the backup.
Usually for installing gdb in windows, You have to 2 ways to install:
1) use ready-made binaries that were build and compiled from GNU gdb by some provider (easy to install)
use TDM-GCC binaries provided from the following URL and that is including inturn the gcc complier and also gdb debugger.
http://tdm-gcc.tdragon.net/
use Equation package inside which GNU GDB was already compiled and built.
http://www.equation.com/servlet/equation.cmd?fa=gdb
2) use minimal mingw or cygwin package then after install gdb inside it.
Install either mingw or cygwin inside which GDB is already shipped
Open cygwin or mingw terminal and just type the following to make sure it is already installed
$ gdb --version
Hint: if you did not find gdb installed, simply open the cygwin or mingw package installer and make sure you already check gdb
Hint: getting and installing a debug build of the OHRRPGCE is providing useful information about crashes.
From cygwin or mingw terminal, Start gdb using the following
c:\mingw\bin\gdb.exe program_to_debug.exe
REF: http://rpg.hamsterrepublic.com/ohrrpgce/GDB_on_Windows
The TDM GCC/MinGW32 builds installer includes gdb. It's gcc 4.4.x with all the core binary packages required for basic Windows development, and is widely used without any unusual problems.