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.

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.

The makefile defines several variables:

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 step1, step2, ..., step5 goals. stepi (for i>1) makes stepi-1 before performing its own work. All step products are installed by in the $(PREFIX) directory.

The install goal builds all products and copies them in $(INSTALLATION_DIR) directory, that is by default /usr/local/i386-mingw32-3.4.4/.

The build_binary_package just builds a package from a previously installation package (see here for more details).

The build_source_disk_image builds a DMG file that contains all source tarballs, makefile, all command files, ... exactly like the one you have downloaded.

The cleanstepi steps delete files from $PREFIX directory. They do not modify $(INSTALLATION_DIR) contents.

The 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.

The uninstall removes $(INSTALLATION_DIR) directory, that a install goal execution has previously populated.

Theses are approximative durations of build steps, for an iMac G5 1,8 GHz:

Building binutils is very easy: configure them, build them and install them succeeded at the first attempt.

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 $(PREFIX)/$(TARGET)/include/ directory.

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

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 "AS=i386-mingw32-as".

As for previous step.

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, java needs C++.

I have implemented a three-stage process for the build_binary_package makefile goal:

1. build and install tools by calling step5 goal;
2. use PackageMaker as command line tool, for building a package from the MinGW-binaries.pmproj project file;
3. build a DMG file from the package.

However, using 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.

The MinGW-binaries.pmproj project file uses pathes at three locations:

1. Installer Interface tab, Show Interface Installer Editor button, background image; the relative path would be: files_for_package_maker/gerwinski-gnu-head.gif;
2. Installer Interface tab, Show Interface Installer Editor button, License file; the relative path would be: files_for_package_maker/License.txt;
3. Contents tab, Root text field; the relative path would be: products.

The 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-3.3 and 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.

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

With 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 config.log file.

See here.

Here is the full build log, on an Intel Mac: