MinGW - Frequently Asked Questions

If you have any further questions, please refer them to the MinGW mailing list . This page is updated by the MinGW Developers as time permits. The Q&A provided here were obtained from the MinGW mailing list, its members, various MinGW related web sites and experience. We would like to thank all who have contributed to this FAQ.


What is MinGW?

MinGW ("Minimalistic GNU for Windows") refers to a set of runtime headers, used in building a compiler system based on the GNU GCC and binutils projects. It compiles and links code to be run on Win32 platforms... providing C, C++ and Fortran compilers plus other related tools. If you see references to "mingw32" instead of "MinGW", they are referring to the same compiler system. The project's name changed from mingw32 to MinGW is to prevent the implication that MinGW will only works on 32 bit systems (as 64 and higher bit machines become more common, MinGW will evolve to work with them). MinGW uses the Microsoft runtime libraries, distributed with the Windows operating system. Unlike other ports of GCC to Windows, the runtime libraries are not distributed using Gnu's General Public License (GPL). You, therefore, do not have to distribute your source code with your programs unless, of course, you use a GPL library in your programs..

Check out the project history for the interesting story of How MinGW Began.

Back to index


What is MSYS?

MSYS, a contraction of "Minimal SYStem", is a POSIX-like command line interpreter (CLI) environment, suitable as an alternative to the Windows Command Prompt, (a.k.a. cmd.exe), for use in situations where Bourne Shell command language is preferred to the native language of Windows commands. Typically used with MinGW, (but by no means restricted to such use), it provides a Bourne Shell CLI, (GNU bash), a hand picked selection of external POSIX commands, (primarily those identified by the GNU Coding Standards, as prerequisites for executing GCS conforming configure scripts), and the GNU make tool. This allows most of the GNU packages to create a Makefile, simply by executing the configure script, (which is provided by the package); this, in turn, can be interpreted by GNU make, to build the package using the native MinGW version of GCC.

The POSIX layer used by MSYS is a fork of the 1.3.3 version of Cygwin . Cygwin is a full POSIX layer and UNIX-like environment for Win32 providing both server and client utilites.

For more MSYS-specific information, please see the MSYS section of this website.

Back to index


What is w32api?

The w32api is the package of headers and import libraries to support the Win32 Application Programming Interface as created by Microsoft. The MinGW development team are the current maintainers of the w32api since without that package Windows Programming would not be possible. The package was created by Anders Norlander and it's license is also non-restrictive. For more information see the file README.w32api .

Back to index


Where can I get MinGW?

Initially, MinGW was an assortment of individual packages... the MinGW runtime, various applications built using that runtime (gcc, ld, etc.), and other useful components (the w32api headers needed to code for the Win32 API). Developers "rolled their own" MinGW environments by downloading the latest versions of each individual package needed. This was necessary given the dynamic nature of early package versions (updates being posted constantly)... but was oftentimes confusing for newbies, and made it difficult for application/library vendors to design products that build with a "standard" MinGW environment.

Therefore, around mid-2001 when development had matured and updates were not being packaged as rapidly, the decision was made to create a single-file distribution of the standard MinGW environment. This single archive contains the files from each component package, bundled and ready to extract. The individual component packages are still available for download... if a particular package is updated in between releases of the overall distribution, it's possible to simply drop the newer package in place over a distribution install.

MinGW files are hosted by SourceForge. For more information and links to download, visit the Download page.

Back to index


How is MinGW licensed?

When Colin Peters released the MinGW runtime he placed the source into the public domain. No one owns a copyright (C) to the source because of this. You as a software manufacturer are free to use the MinGW runtime in your proprietary and OpenSource software as you see fit. The only thing you can't do is to claim ownership of the source and use Colin Peters' name, the MinGW name or the name of any of it's contributors in endorsement of any product.

For those interested in the actual legal details and technical points regarding copyright of the MinGW compiler system, copyright information is included in the headers and the source files of the compiler distribution package. The following also applies:

Here are some further reference sources for the various licenses that apply to pieces of the MinGW distribution:

Back to index


What is the current version?

Please refer to the release section of the download page located here.

Back to index


Can I use older versions?

It's highly recommended that you use the latest version of MinGW. Older versions may have more bugs and can be more difficult to install or use than the latest version. Please be sure that you have downloaded and are working with the latest version, especially if you are having any difficulties with installation or use. If you are not sure of your version, you can type gcc -v to find out what you are using.

Back to index


What Languages Are Supported?

As of MinGW-2.0.0-3.exe, MinGW carries support for C, C++, ObjC, and Fortran 77.  Ada is available as a seperate binary, while Java (GCJ) is implemented as a release candidate.  Continual work is being done with the hope of it being included in the next major release.  And last, but not least Pascal is available as a contributed package (GPC).

Back to index


Why is my C++ binary so large?

C++ programs using the Standard Template Library (ie/ #include <iostream>) cause a large part of the library to be statically linked into the binary. The need to statically link the stdc++ into the binary is two fold. First MSVCRT.dll does not contain C++ stdlib constructs. Second the legal implications of generating a libstdc++.dll are restricted by the licensing associated with the library. If you wish to keep your file size down use strip to remove debugging information and other verbatim found in the binary.

strip --strip-all SOMEBINARY.exe

Back to index


How do I execute configure scripts?

Applications using a UNIX-style build process will typically require a shell environment and set of POSIX tools, for executing configure scripts and building the application. The Cygwin environment was once the only choice available to fill this role, although recently the MSYS environment was released to offer MinGW developers a more lightweight alternative. The use of both these environments with MinGW is described in more detail below.

Back to index


How do I use MinGW with MSYS?

It's easy to configure an MSYS environment for MinGW useage, since there is no overlap in functionality to contend with (as there is with Cygwin). Simply decompress the contents of each archive into directories of your choosing, and add the MinGW "/bin" subdirectory to your PATH (either within MSYS's " /etc/profile" or in your overall system PATH). There is no need to add MSYS's "/bin" to your system PATH.

You may install the MinGW and MSYS packages anywhere on your filesystem, even nesting one within the other (creating a " mingw" subdirectory beneath your "msys" directory, for instance). However, it is important to remember that NO executables other than what ships with MSYS should be placed in the MSYS " bin" subdirectory. Therefore, do not attempt to "merge" the two packages.

Back to index


How do I use MinGW with Cygwin?

For those who would like to use the Cygwin environment for development, yet generate non-Cygwin-dependant executables, a much easier option to "-mno-cygwin" does exist. Simply install Cygwin and the MinGW distribution in seperate directories (i.e. "C:\CYGWIN" and "C:\MINGW"), and make sure that the "/bin" subdirectory beneath your MinGW installation comes before Cygwin's "/bin" subdirectory in your PATH environment variable (i.e. "PATH=%PATH%;C:\MINGW\BIN;C:\CYGWIN\BIN"). This will allow you access to all the UNIX tools you want, while ensuring that the instance of GCC used is the MinGW version.

Bear in mind that within the "/etc/profile" file, Cygwin by default places "/usr/local/bin", "/usr/bin", and "/bin" ahead of your system-level PATH. Therefore, it is not enough to have the MinGW's "/bin" ahead of Cygwin in your Windows path... it must also be set to come first within the Cygwin environment (either by modifying "/etc/profile" or setting it manually).

Back to index


Is support provided for COM?

MinGW has some support for COM programs. Programmers have had much better luck writing COM applications in C than C++. Work is in progress to improve support. Check the MinGW mailing list archives for more details on COM and more links to example files.

Back to index


How can an MSVC program call a MinGW DLL, and vice versa?

Assume we have a testdll.h, testdll.c, and testmain.c. In the first case, we will compile testdll.c with MinGW, and let the MSVC-compiled testmain call it. You should use

gcc -shared -o testdll.dll testdll.c \
    -Wl,--output-def,testdll.def,--out-implib,libtestdll.a

to produce the DLL and DEF files. MSVC cannot use the MinGW library, but since you have already the DEF file you may easily produce one by the Microsoft LIB tool: lib /machine:i386 /def:testdll.def

Once you have testdll.lib, it is trivial to produce the executable with MSVC:

cl testmain.c testdll.lib

Now for MinGW programs calling an MSVC DLL. We have two methods. One way is to specify the LIB files directly on the command line after the main program. For example, after

cl /LD testdll.c

use gcc -o testmain testmain.c testdll.lib

The other way is to produce the .a files for GCC. For __cdecl functions (in most cases), it is simple: you only need to apply the reimp tool from Anders Norlander (since his web site is no longer available, you may choose to download here a version enhanced by Jose Fonseca):

reimp testdll.lib
gcc -o testmain testmain.c -L. -ltestdll

However, for __stdcall functions, the above method does not work. For MSVC will prefix an underscore to __stdcall functions while MinGW will not. The right way is to produce the DEF file using the pexports tool included in the mingw-utils package and filter off the first underscore by sed:

pexports testdll.dll | sed "s/^_//" > testdll.def

Then, when using dlltool to produce the import library, add `-U' to the command line:

dlltool -U -d testdll.def -l libtestdll.a

And now, you can proceed in the usual way:

gcc -o testmain testmain.c -L. -ltestdll

Hooray, we got it.

Back to index


How can a JNI DLL be created?

JNI is the Java Native Interface, you will need to download and install the Java SDK.  Note the installation directory (ie/ c:\j2sdk1.4.1_02 ) for use later.  If you are using MSYS add a line similiar to the following in /etc/fstab and then restart MSYS:

c:/j2sdk1.4.1_02      /java

In MSYS the JNI DLL can be generated using the following (NOTE: -Wl has an 'L' not a '1'):

gcc -Wall -D_JNI_IMPLEMENTATION_ -Wl,--kill-at \
  -I/java/include -I/java/include/win32 \
  -shared -o JavaImp.dll someJavaImp.c

In a standard command console it can be generated as follows (one continuous line):

gcc -Wall -D_JNI_IMPLEMENTATION_ -Wl,--kill-at
  -Ic:/j2sdk1.4.1_02/include -Ic:/j2sdk1.4.1_02/include/win32
  -shared someJavaImp.c -o JavaImp.dll

Where JavaImp.dll should be named whatever you refer to the library as in your .java file.  To use the above dll you would refer to it as follows in your java classes code:

System.loadLibrary( "JavaImp" );

If you encounter problems ensure your CLASS_PATH and PATH are set appropriately for your environment.  Please refer to Java Native Interface for further details on using a JNI DLL in java code.

Back to index


How can I build a cross compiler?

Cross-compiling refers to building applications for one platform, with development occuring on another platfrom (i.e. compiling MS-Windows executables from within a Linux environment, or vice-versa). As GCC is found on literally dozens of platforms, it is theoretically possible to use the MinGW runtime in creating a cross-compilation development environment in many scenerios.

There is a very old out-of-date mingw-cross-howto.txt written by Mumit Khan and stored on his site you can use. You'll have to update the packages. This needs to be rewritten, any volunteers? If so, please speak up in the mingw-users list.

A more upto date HOWTO complete with a script to configure it for you can be found at http://www.libsdl.org/extras/win32/cross/README.txt .

You'll want to visit the crossgcc mail list archives . You'll also find a link to a crossgcc FAQ and another for an ftp download site of some useful scripts on the archives search page.

There are also some pre-built versions:

Back to index


What's the difference between gcc.exe and mingw32-gcc.exe?

The mingw32-gcc, mingw32-g++, etc. binaries exist as an aid to cross development. They are created in a typical build of gcc. They are therefore distributed as the maintainers of GCC meant them to be. The gcc.exe indicates that the binary produces binaries for a target equal to the build, while the mingw32-gcc binary produces binaries to be executed on the mingw32 target.

Back to index


What is a Makefile and how do I create one?

A Makefile is a plain textfile that is used to reduce repeatitive commands such as compiler invocation.  All indentation in a Makefile should be done with tabs not spaces.  A simple example of a Makefile is as follows and is invoked by typing 'make':

all:
     gcc -Wall -O3 -o hello.exe hello.cpp

The following is a more complex example that shows the use of variables and other features:

# this is a comment
SRC=hello.c main.c
OBJ=$(SRC:.c=.o) # replaces the .c from SRC with .o
EXE=hello.exe

CC=gcc
CFLAGS=-Wall -O3
LDFLAGS=-mwindows
RM=rm

%.o: %.c         # combined w/ next line will compile recently changed .c files
     $(CC) $(CFLAGS) -o $@ -c $<

.PHONY : all     # .PHONY ignores files named all
all: $(EXE)      # all is dependent on $(EXE) to be complete

$(EXE): $(OBJ)   # $(EXE) is dependent on all of the files in $(OBJ) to exist
     $(CC) $(OBJ) $(LDFLAGS) -o $@

.PHONY : clean   # .PHONY ignores files named clean
clean:
    -$(RM) $(OBJ) core    # '-' causes errors not to exit the process

This Makefile can be invoked in any of the following ways:

# for the above file will compile everything required by the all label
make

# effectively the same as the previous line
make all

# 'clean' the project of stale files
# for this Makefile, remove hello.o, main.o and core
make clean

# clean and then build all
make clean all

# build all and then clean
make all clean

For further information on Makefiles please refer to the GNU make documentation.

Back to index


Why is make named mingw32-make.exe?

The "native" (i.e.: MSVCRT dependent) port of make is lacking in some functionality and has modified functionality due to the lack of POSIX on Win32. There also exists a version of make in the MSYS distribution that is dependent on the MSYS runtime. This port operates more as make was intended to operate and gives less headaches during execution. Based on this, the MinGW developers/maintainers/packagers decided it would be best to rename the native version so that both the "native" version and the MSYS version could be present at the same time without file name collision.

Back to index


How to remove DOS command windows?

In the link step add a -mwindows switch to the command line.

Back to index


How can I report bugs?

Please refer to the Reporting Bugs page

Back to index