Mingw

MinGW (historically, MinGW32) is a way to cross-compile Windows binaries on Linux or any other OS. It can also be used natively on Windows to avoid using Visual Studio, etc.

More information on the MinGW project can be found at MinGW.org.

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. A remote debugger (with a Windows target machine) is a possibility but a long shot.

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
If files are left over (such as libraries and things you have added), you will be prompted to remove the  directory recursively.

Using Portage
Some things work. Most things do not. Try with  after a failed build, then selectively add USE flags you need. If that does not work, then you probably cannot use Portage to install the package desired for use with MinGW.

Using Portage, 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

Emerging :

GDBM
These are "Standard GNU database libraries" according to Portage. Many libraries and applications depend on this. Successfully compiled before, but the current version in Portage does not compile. A patch is very much needed.

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

libssp
The GCC useflag sys-devel/gcc[libssp ] has been masked, as it is usually already provided by libc. Apparently msvcrt does not provide libssp, so it is recommended to re-enable this useflag for cross compilation (see package.use.mask):

OpenSSL
Follow this guide:

SDL Example
Emerge SDL:

Try compiling this source code (save to ).

Use the following command to build:

Test with Wine (requires SDL.dll to be somewhere in Wine's, which includes the same directory as the EXE):

If you get a window named SDL_app, then it worked. The window will automatically exit after about 5 seconds (the Windows  function halts execution for 5000 milliseconds).

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  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 (however do note that Chrome uses this library for threading on Windows). Regardless, many ported applications to Windows end up using POSIX Threads for Win32 because of convenience. With this library you can 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  ).

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: In main: creating thread 0 In main: creating thread 1 Thread #0 responding. In main: creating thread 2 Thread #1 responding. In main: creating thread 3 Thread #2 responding. In main: creating thread 4 Thread #3 responding. Thread #4 responding. Completed join with thread 0, status = 0 Completed join with thread 1, status = 0 Completed join with thread 2, status = 0 Completed join with thread 3, status = 0 Completed join with thread 4, status = 0

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  (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
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).

Emerging a toolchain fail with error: Missing digest for *.ebuild
Add the following to the crossdev overlay metadata: