Mingw

Mingw32 is a way to cross-compile Windows 32-bit binaries on Linux or any other OS. It can also be used natively on Windows to avoid using Visual Studio, etc.

This article will keep track of libraries that work and workarounds.

Mingw32 Toolchain
Start with emerging the tool:

Now with this tool, emerge the mingw32 toolchain:

You may try adding and/or. These have not been known to build. will give you GDB and likely will work, but it is not very useful on Linux because MingW GCC by default makes PE's (EXE files), not ELF files, and gdb has no idea how to run an EXE file on Linux.

GCC cannot support all its features in a Mingw32 toolchain; the following USE flag have been noted to be safe:

After setting this, reemerge the mingw32 GCC with the new USE flags:

Other notes about the toolchain:
 * GCJ sources will not compile due to missing makespec files that do not get installed (copying from Mingw from Windows does not work either)
 * OpenMP is forcefully disabled in the ebuild for the time being even if you enable it in your USE flags

Uninstallation
Note that any libraries built against this toolchain will NOT be removed. Remove all libraries that do not come with the toolchain prior to removal.

Using Portage
If you wish to build with Portage (recommended), you may run into problems such as the following:


 * Application wants GDBM (see below)
 * Application wants to link with ALSA/OSS/Mesa/other library only useful to X or Linux

To build using Portage you must set your variables while emerging. For example, emerging :

GDBM
These are "Standard GNU database libraries" according to Portage. LOTS of libraries and applications depend on this. Successfully compiled before, but the current version in Portage does not compile. Not able to compile for the moment. Error in gdbmopen.c. A patch is very much needed.

To get around this problem for the moment, try building with as well.

There are many patched versions of typical UNIX apps like GDBM here.

SDL Example
Get the latest SDL via HG.

Compile it with the following commands:

To install you need to be root:

Try compiling this source code (save to ).

Use the following command to build:

Test with Wine (requires SDL.dll):

If you get a window named SDL_app that closes shortly, then it worked. Because there is no event loop, the window will draw then close shortly after initialising SDL.

Porting POSIX Threads to Windows
Windows thread functions seem to work fine with Mingw. The following example code will compile without error:

Compile with:

(The call to Sleep will make the thread creation a little more closer to POSIX, more in order, and there will not be duplicate runs.)

However, many applications rely upon POSIX threads and do not have code for Windows thread functionality. The POSIX Threads for Win32 project provides a library for using POSIX thread-like features on Windows (rather than relying upon Cygwin). It basically wraps POSIX thread functions to Win32 threading functions ( -> for example). Be aware that not everything is implemented on either end, and it could be buggy. The library also has not been updated since 2006. Regardless, many ported applications to Windows end up using POSIX Threads for Win32 because of convenience. With this library you can of course get the best of both worlds as Windows thread functions work fine as show above.

To get Pthreads for Win32:
 * 1) Go to the Sourceware FTP and download the header files to your includes directory for Mingw (for me this is ).
 * 2) Go to the Sourceware FTP and download only the .a files to your lib directory for Mingw (for me this is ).'
 * 3) At the same directory, get the DLL files (only pthreadGC2.dll and pthreadGCE2.dll; others are for Visual Studio) and place them in the bin directory of your Mingw root (for me this is ).

Example POSIX threads code:

Compile with:

With we can see that we need pthreadGC2.dll. If you linked with -lpthreadGCE2 (exception handling POSIX threads), you will need mingwm10.dll, pthreadGCE2.dll, and possibly libgcc_s_sjlj-1.dll (last one only if you do not compile with CFLAG  with  ). If you link with a very specific version of msvcrt.dll, your application will need to be distributed with that file as well.

Copy the DLL file(s) required to the directory and test with Wine. For example:

If all goes well, you should see output similar to the following:

Wine and %PATH%
Like Windows, Wine supports environment variables. You may specify the path of your DLLs (for example, the Mingw bin directory) in the registry at (I believe this is the same in Windows); (for me this value would be ). I recommend against this as you might forget to distribute DLLs with your application binaries.

No need for -lm
If you  and make use of any of its functions, there is no need to link with the standard C math library using the   switch with gcc or g++.

DirectX
You will have to get some of the DirectX 8 headers from elsewhere but they are perfectly usable.

DirectX 9 headers and libs are included. Link with. For the math functions (such as, unlike Windows, you need to dynamically link with   and then include   (where you get this file SHOULD be from Microsoft's SDK). This is the same for DirectX 8.

There is no support for DirectX 10 or 11 yet. Minimal support for Direct2D has been implemented via a patch (search the official mailing list of MinGW).