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?
- What is MSYS?
- What is w32api?
- Where can I get MinGW?
- How is MinGW licensed?
- What is the current version?
- Can I use older versions?
- What Languages Are Supported?
- Why are C++ programs so large?
- How do I execute configure scripts?
- How do I use MinGW with MSYS?
- How do I use MinGW with Cygwin?
- Is support provided for COM?
- How can an MSVC program call a MinGW DLL, and vice versa?
- How can a JNI DLL be created?
- How can I build a cross compiler?
- What's the difference between gcc.exe and mingw32-gcc.exe?
- What is a Makefile and how do I create one?
- Why is make named mingw32-make.exe?
- How to remove DOS command windows?
- How can I report bugs?
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.
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.
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 .
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.
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:
- The MinGW basic runtime system, which is basically the glue to the underlying operating system, is completely in the public domain. The runtime system includes MinGW headers (such as stdio.h), libraries (such as libmingw32.a) and import libraries for CRTDLL/MSVCRT.
- W32API, which consists of the headers and import libraries related to WIN32 API access, is released under
- copyright . The copyright agreement states no restrictions are placed on programs or object files compiled with the library.
- Mingw development tools, which include compilers, linkers, other tools in the bin directory, etc., are released under the GNU General Public License.
- Profiled code, which is code compiled and
linked with the
-pgoption for runtime profiling, also falls under the GNU General Public License. CAUTION: do not distribute proprietary source with profiling enabled. The profiling library is covered by the GPL which infects your product to conform to the GPL as well.
Here are some further reference sources for the various licenses that apply to pieces of the MinGW distribution:
- GNU General Public License, http://www.gnu.org/copyleft/gpl.html
- GNU Lesser General Public License, http://www.gnu.org/copyleft/lgpl.html
- For more information on the copyleft concept, http://www.gnu.org/copyleft/
What is the current version?
Please refer to the release section of the download page located here.
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.
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).
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
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.
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.
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).
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.
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.libgcc -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.
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.
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:
- Linux: mingw32-linux-x86-glibc-2.2.tar.gz
- If you know of others let us know.
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.
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.
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.
How to remove DOS command windows?
In the link step add a -mwindows switch to the command line.
How can I report bugs?
Please refer to the Reporting Bugs page