. HugeDomains.com - LoadupDates.com is for sale (Loadup Dates)

Hundreds of thousands of premium domains

Questions? We're here to help! Call today:


LoadupDates.com is for sale

Buy Now: $2695
  • Take Immediate ownership
  • Transfer the domain to the Registrar of your choosing
Finance This Domain: $2695 12 monthly payments of $225
  • 12 monthly payments, only $224.58 per month
  • Start using the domain today See details

Talk to a domain expert: 1-303-893-0552

Hurry - once it's sold this opportunity will be gone!

Besides being memorable, .com domains are unique: This is the one and only .com name of its kind. Other extensions usually just drive traffic to their .com counterparts. To learn more about premium .com domain valuations, watch the video below:

Turbocharge your Web site. Watch our video to learn how.

Improves Your Web Presence

Get noticed online with a great domain name

73% of all domains registered on the Web are .coms. The reason is simple: .com is the where most of Web traffic happens. Owning a premium .com gives you great benefits including better SEO, name recognition, and providing your site with a sense of authority.

Here's What Others Are Saying

Since 2005, we've helped thousands of people get the perfect domain name
  • I was searching domains name over internet and found HugeDomains - they have very short and sweet names and plus point is they provide custom payments - which anyone can afford and can pay monthly and that's what I did. so far I purchased three domain names from them worth USD 10k and very happy with their support. Love it - thank you so much HugeDomains - Web Tech, 7/10/2018
  • Such an easy way to buy my domain name! I love the 0% payment plan too. - Damon Lomax, 7/9/2018
  • Very easy & efficient process. Couldn't have been easier. - Valerie Darling, 7/2/2018
  • More testimonials


Own this domain today

Our Price: $2,695 (USD)

Speak with a domain specialist!
Call us: 1-303-893-0552 M-F 9am - 5pm MST
Other Domains You Might Like

© 2018 HugeDomains.com. All rights reserved.

mingwformac [Cross GCC on Mac OS X]

User Tools

Site Tools


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 Variables

The makefile defines several variables:

Variable Default Value Meaning
TARGET i386-mingw32 Target name
GCC_VERSION 3.4.4 The GCC version used for MinGW port
MINGW_VERSION $(GCC_VERSION)-20050522-1 the MinGW port full name
PREFIX $(PWD)/products Where products are installed by stepi goals)
INSTALLATION_DIR /usr/local/$(TARGET)-$(GCC_VERSION) Where products are installed (by install goal)
NATIVE_COMPILER gcc-3.3 The Mac OS X native compiler used for compiling tool chain; I have used gcc-3.3, provided in Developer Tools 2.2
LANGUAGES –enable-languages=c++,objc,ada,java,f77 Languages built by fifth step

Build Steps

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.

Command File Makefile Goal Operation
build_step1.commandstep1 Builds and installs binutils in $PREFIX directory
build_step2.commandstep2 performs step1, then builds and installs C compiler in $(PREFIX) directory
build_step3.commandstep3 performs step2, then builds and installs Win32 API in $(PREFIX) directory
build_step4.commandstep4 performs step3, then builds and installs MinGW Runtime in $(PREFIX) directory
build_step5.commandstep5 performs step4, then builds and installs other compilers in $(PREFIX) directory
build_step5and_install.commandinstall step5, then copy products in $(INSTALLATION_DIR) directory
build_step5and_binary_distribution.commandbuild_binary_package builds a package embbedded in a DMG file
build_source_disk_image.commandbuild_source_disk_image builds the source tarballs distribution in a DMG file (like the one you have downloaded)

Cleaning and Uninstalling

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.

Command File Makefile Goal Operation
clean_step1.commandcleanstep1 removes $(PREFIX) directory
clean_step2.commandcleanstep2 removes C compiler, then performs cleanstep3
clean_step3.commandcleanstep3 removes $(PREFIX)/$(TARGET)/lib/libadvapi32.a file, then performs cleanstep4
clean_step4.commandcleanstep4 removes $(PREFIX)/$(TARGET)/lib/libcoldname.a file, then performs cleanstep5
clean_step5.commandcleanstep5 Removes C++ compiler from $(PREFIX) file
uninstall.commanduninstall removes $(INSTALLATION_DIR) directory

Build Steps Durations

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

Step Building… Duration
1binutils 8'
2C compiler 9'
3Win32 API 1'
4MinGW Runtime 1'
5C++ Compiler Only 16'
5All Compilers (C++, Objective-C, Java, Ada, Fortran 77) 1h 6'

Building details

Step 1: building binutils

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

Step 2: building C compiler

Copying headers

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.

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

Step 4: building MinGW runtime

As for previous step.

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

Building the binary distribution

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.

Of course, for building successfully, you must replace my absolute pathes with yours.

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.

Building the source distribution

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.

Release 2

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.

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.

Universal binaries

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.

MinGW Packages

See here.

Build log

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

mingwformac.txt · Last modified: 2006/12/30 11:18 (external edit)