Building MinGW for Mac OS X
You need Apple Developer Tools, that you can download from Apple Developer Connection. I have installed XCode Tools 2.2, and I have used
gcc-3.3 for cross-compiling MinGW.
MinGW for Mac OS X Source package is available here as a DMG file.
Mount DMG file, and copy its contents in any directory.
Building steps overview
All operations are organized by the
makefile file. For making things easier, I have included numerous shell script files (file with
.command extensions). Theses files just invoke
make with a specific goal.
makefile defines several variables:
|Variable ||Default Value ||Meaning
|The GCC version used for MinGW port
|the MinGW port full name
|Where products are installed by
|Where products are installed (by
|The Mac OS X native compiler used for compiling tool chain; I have used gcc-3.3, provided in Developer Tools 2.2
|Languages built by fifth step
As full building takes a while, I have divided it in five steps, as described in the following table. All building steps are provided by the
makefile file, which defines the
stepi-1 before performing its own work. All step products are installed by in the
install goal builds all products and copies them in
$(INSTALLATION_DIR) directory, that is by default
build_binary_package just builds a package from a previously installation package (see here for more details).
build_source_disk_image builds a DMG file that contains all source tarballs, makefile, all command files, … exactly like the one you have downloaded.
|Command File ||Makefile Goal ||Operation
|Builds and installs binutils in
step1, then builds and installs C compiler in
step2, then builds and installs Win32 API in
step3, then builds and installs MinGW Runtime in
step4, then builds and installs other compilers in
|step5, then copy products in
|builds a package embbedded in a DMG file
|builds the source tarballs distribution in a DMG file (like the one you have downloaded)
Cleaning and Uninstalling
cleanstepi steps delete files from
$PREFIX directory. They do not modify
cleanstep1 step is a clean all operation. Other steps do not remove all files created from the corresponding build steps, but only some files that trigger build steps.
$(INSTALLATION_DIR) directory, that a
install goal execution has previously populated.
|Command File ||Makefile Goal ||Operation
|removes C compiler, then performs
$(PREFIX)/$(TARGET)/lib/libadvapi32.a file, then performs
$(PREFIX)/$(TARGET)/lib/libcoldname.a file, then performs
|Removes C++ compiler from
Build Steps Durations
Theses are approximative durations of build steps, for an iMac G5 1,8 GHz:
|Step ||Building… ||Duration
|2||C compiler ||9'
|3||Win32 API ||1'
|4||MinGW Runtime ||1'
|5||C++ Compiler Only ||16'
|5||All Compilers (C++, Objective-C, Java, Ada, Fortran 77) ||1h 6'
Step 1: building binutils
binutils is very easy: configure them, build them and install them succeeded at the first attempt.
Step 2: building C compiler
C Compiler needs header files for compiling successfully. Headers from gcc-core tarball are not sufficient. In fact, C compiler needs headers from win32 api and MinGW runtime, that we copy in
Handling end of line warning
gcc warns each time it finds an include file that is not terminated by an end of line, that is a CRLF for MinGW (as it deals with Windows formatted text files). Our cross compiler will run on Mac OS X, and will process text files with with CR, LF or CRLF end of line marks. The result is you get many warnings when included files use a LF or a CR as end of line mark. By default, gcc provides no command line option to disable this warning.
I have found here a GCC patch that disables it. However, this patch is available for GCC 3.3.3, and trying to apply it to GCC 3.4.4 fails.
In fact, options handling in 3.4.4 is very different from 3.3.3. So I have written my own patch. The
patch files are located in the
patches directory. The patches are applied to the C compiler sources before performing configuration.
By default, our compiler outputs no warning for any of end of line mark (if you want to re-enable it, use -Weof-newline command line option, that warns when a file does not end with a CRLF).
Step 3: building win32 api
No particular point to hilite about configuration. Invoking make from building and installing needs to associate specific shell variables to cross tools full names, for example
Step 4: building MinGW runtime
Step 5: building other compilers
Building all compilers takes a while (1h 6' for all languages). I have introduced the
LANGUAGES makefile variable, for selecting the languages you want to build.
Note the languages are not independant: for example,
Building the binary distribution
I have implemented a three-stage process for the
build_binary_package makefile goal:
build and install tools by calling
PackageMaker as command line tool, for building a package from the
MinGW-binaries.pmproj project file;
build a DMG file from the package.
PackageMaker as command line tool is not as easy as I thought it. Performing build from GUI was working fine, althought trying to build from makefile was allways failing.
At last, I realized that PackagerMaker Version 2.1 (122) cannot build successfully from command line when the project file contains relative pathes.
So I change all relative pathes to absolute ones and build process works correctly.
|Of course, for building successfully, you must replace my absolute pathes with yours.
MinGW-binaries.pmproj project file uses pathes at three locations:
Installer Interface tab, Show Interface Installer Editor button, background image; the relative path would be:
Installer Interface tab, Show Interface Installer Editor button, License file; the relative path would be:
Contents tab, Root text field; the relative path would be:
Building the source distribution
build_source_disk_image makefile goal just builds a DMG file using
hdutil command line tool. This is the way I distribute the source package.
For release 2, I have used XCode 2.4.1;
gcc-4.0 are both available, but building the distribution fails with
gcc-3.3 on an Intel Mac. Running the scripts builds the tool chain for current platform, i.e. ppc binaries on a ppc based Mac, and Intel binaries on an Intel based Mac.
PackageMaker 2.1.1 (123)
With XCode 2.4.1, PackageMaker 2.1.1 (123) is provided. This release handles relative pathes. I have modified the
file so that it uses now only relative pathes, making obsolete path adjustments.
I have tried on a ppc Mac to build universal binaries, by defining in the makefile (line 74) :
NATIVE_COMPILER := gcc-3.3 -arch pcc -arch i386
But this setting make the step 1 to fail, with the message:
checking for powerpc-apple-darwin8.8.0-gcc… gcc-3.3 -arch ppc -arch i386
checking for suffix of object files… configure: error: cannot compute suffix of object files: cannot compile
gcc-4.0, the error message is:
checking how to run the C preprocessor… /lib/cpp
configure: error: C preprocessor ”/lib/cpp” fails sanity check
See `config.log' for more details.
I have found no interesting details in
Here is the full build log, on an Intel Mac: