Finding Dlls Required of a Win Exe on Linux (Cross-Compiled with Mingw)

Cross compiling from MinGW on Fedora 12 to Windows - console window?

I suspect that your theme problem is te result of a missing application manifest

The reason that your app gets a console is simple. Windows apps come in two flavors, Console and GUI. The difference is a bit in the PE header of the EXE. GCC's default is to generate a Console app, and e8johan explains how to change that (-Wl,-subsystem,windows). There's also some fooling around with entry points (GUI's are expected to use WinMain(), and console apps main()) but MinGW should take care of that

How do I compile and link a 32-bit Windows executable using mingw-w64

That depends on which variant of toolchain you're currently using. Both DWARF and SEH variants (which come starting from GCC 4.8.0) are only single-target. You can see it yourself by inspecting the directory structure of their distributions, i.e. they contain only the libraries with either 64- or 32-bit addressing, but not both. On the other hand, plain old SJLJ distributions are indeed dual-target, and in order to build 32-bit target, just supply -m32 flag. If that doesn't work, then just build with i686-w64-mingw32-g++.

BONUS

---

By the way, the three corresponding dynamic-link libraries (DLLs) implementing each GCC exception model are

1. libgcc_s_dw2-1.dll (DWARF);
2. libgcc_s_seh-1.dll (SEH);
3. libgcc_s_sjlj-1.dll (SJLJ).

Hence, to find out what exception model does your current MinGW-w64 distribution exactly provide, you can either

1. inspect directory and file structure of MinGW-w64 installation in hope to locate one of those DLLs (typically in bin); or
2. build some real or test C++ code involving exception handling to force linkage with one of those DLLs and then see on which one of those DLLs does the built target depend (for example, can be seen with Dependency Walker on Windows); or
3. take brute force approach and compile some test code to assembly (instead of machine code) and look for presence of references like ___gxx_personality_v* (DWARF), ___gxx_personality_seh* (SEH), ___gxx_personality_sj* (SJLJ); see Obtaining current GCC exception model.

Setting up MinGW in Windows 7 to compile adequately portable C++ code

All you need to do for your exe to work is either put the GCC DLLs somewhere in PATH (by adding C:\MinGW\bin to your PATH) or compile all your code to link statically to the GCC runtime DLLs by using "-static" as a linker argument. When you distribute your executable, you'll need to make sure libgcc*.dll and libstdc++-6.dll are both installed alongside your executable. (if you're still using MinGW.org's toolchain, time to step up to MinGW-w64, who don't have a mingwm10.dll or whatever it's called).

The GCC DLLs are much the same as Visual Studio's C++ redistributables; to run code built with a certain VS version, you need the DLLs. Linking statically is the only way to not have that problem.

Also, get a cross-platform build system like CMake. It will make your life a lot easier.

Entry Point Not Found Error on running c++ .exe file after compiling with mingw g++

The problem was with libstd++6.dll. It was solved by using the argument -static-libstdc++ in g++. MinGW was taking libstd++6.dll from Windows instead of the one in MinGW.

libstdc++-6.dll not found

If you are using MingW to compile C++ code on Windows, you may like to add the options -static-libgcc and -static-libstdc++ to link the C and C++ standard libraries statically and thus remove the need to carry around any separate copies of those. Version management of libraries is a pain in Windows, so I've found this approach the quickest and cleanest solution to creating Windows binaries.

---

Related Topics