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-4.0 for cross-compiling i386 Linux gcc.
i386 Linux GCC for Mac OS X Source package is available here as a DMG file.
Mount DMG file, and copy its contents in any directory in a case-sensitive file system.
Use a case-sensitive file System (Unix File System or Mac OS Extended Case-sensitive). Building GLIBC fails in a case-insentive file system (don't ask me why !), with the following error message:
i386-linux-gcc -nostdlib -nostartfiles -shared -o /MYPATH/linux/build_glibc/elf/ld.so \
-Wl,-z,combreloc -Wl,-z,relro -Wl,-z,defs \
/MYPATH/linux/build_glibc/elf/librtld.os -Wl,--version-script=/MYPATH/linux/build_glibc/ld.map \
-Wl,-soname=ld-linux.so.2 -T /MYPATH/linux/build_glibc/elf/ld.so.lds
/MYPATH/linux/build_glibc/elf/librtld.os: In function `process_envvars':
/MYPATH/linux/glibc-2.5/elf/rtld.c:2718: undefined reference to `__open'
/MYPATH/linux/glibc-2.5/elf/rtld.c:2690: undefined reference to `__access'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `dl_main':
/MYPATH/linux/glibc-2.5/elf/rtld.c:1657: undefined reference to `__access'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `_dl_discover_osversion':
../sysdeps/unix/sysv/linux/dl-osinfo.h:96: undefined reference to `__open'
../sysdeps/unix/sysv/linux/dl-osinfo.h:99: undefined reference to `__read'
../sysdeps/unix/sysv/linux/dl-osinfo.h:100: undefined reference to `__close'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `lose':
/MYPATH/linux/glibc-2.5/elf/dl-load.c:817: undefined reference to `__close'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `open_verify':
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1640: undefined reference to `__open'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1652: undefined reference to `__libc_read'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1750: undefined reference to `__lseek'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1751: undefined reference to `__libc_read'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1768: undefined reference to `__lseek'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1769: undefined reference to `__libc_read'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1785: undefined reference to `__close'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `open_path':
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1875: undefined reference to `__GI___xstat64'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1895: undefined reference to `__GI___fxstat64'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1901: undefined reference to `__close'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1922: undefined reference to `__close'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `_dl_map_object_from_fd':
/MYPATH/linux/glibc-2.5/elf/dl-load.c:868: undefined reference to `__GI___fxstat64'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:884: undefined reference to `__close'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1001: undefined reference to `__lseek'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1002: undefined reference to `__libc_read'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:913: undefined reference to `__close'
/MYPATH/linux/glibc-2.5/elf/dl-load.c:1441: undefined reference to `__close'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `_dl_map_object':
/MYPATH/linux/glibc-2.5/elf/dl-load.c:2150: undefined reference to `__close'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `_dl_new_object':
/MYPATH/linux/glibc-2.5/elf/dl-object.c:167: undefined reference to `__getcwd'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `_dl_sysdep_read_whole_file':
/MYPATH/linux/glibc-2.5/elf/dl-misc.c:58: undefined reference to `__open'
/MYPATH/linux/glibc-2.5/elf/dl-misc.c:61: undefined reference to `__GI___fxstat64'
/MYPATH/linux/glibc-2.5/elf/dl-misc.c:79: undefined reference to `__close'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `_dl_start_profile':
/MYPATH/linux/glibc-2.5/elf/dl-profile.c:287: undefined reference to `__open'
/MYPATH/linux/glibc-2.5/elf/dl-profile.c:304: undefined reference to `__GI___fxstat64'
/MYPATH/linux/glibc-2.5/elf/dl-profile.c:298: undefined reference to `__close'
/MYPATH/linux/glibc-2.5/elf/dl-profile.c:335: undefined reference to `__close'
/MYPATH/linux/glibc-2.5/elf/dl-profile.c:355: undefined reference to `__close'
/MYPATH/linux/glibc-2.5/elf/dl-profile.c:320: undefined reference to `__lseek'
/MYPATH/linux/glibc-2.5/elf/dl-profile.c:327: undefined reference to `__libc_write'
/MYPATH/linux/build_glibc/elf/librtld.os: In function `check_one_fd':
/MYPATH/linux/glibc-2.5/csu/check_fds.c:44: undefined reference to `__libc_fcntl'
/MYPATH/linux/glibc-2.5/csu/check_fds.c:75: undefined reference to `__GI___fxstat64'
collect2: ld returned 1 exit status
make: *** [/MYPATH/linux/build_glibc/elf/ld.so] Error 1
make: *** [elf/subdir_lib] Error 2
make: *** [all] Error 2
make: *** [/usr/local/i386-linux-4.1.1/lib/libg.a] Error 2
make: *** [step5] Error 2
All operations are organized by the
makefile file. For making things easier, I have included numerous shell script files (files with
.command extensions). Theses files just invoke
make with a specific goal.
My first intention was to build all products in user space and then to recopy them in their final destination. I noted that did not work. The generated
ld contains absolute pathes, so it does not support to be moved. I think that there is perhaps a solution with
--with-sys-root configure option, but I did not find it.
makefile defines several variables:
|binutils package version|
|The GCC package version|
|GLIBC package version and GLIBC LINUXTHREADS package version|
|Linux libc headers package version|
|The target name|
|Where products are built|
|The Mac OS X native compiler used for compiling tool chain; I have used gcc-4.0, provided in Developer Tools 2.2|
|The directory where the Mac OS X tools are installed|
As full building takes a while, I have divided it in six 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
$(INSTALLATION) directory (so build and clean commands invoke
sudo). The products of each building step is saved in an archive (
products_after_step_i.tar.bz2). At the beginning of each step, the products from preceeding step are restored from the archive.
build_binary_package builds a DMG file that contains an Mac OS X installer file.
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 the source tarballs distribution in a DMG file (like the one you have downloaded)|
You can find here the 448 kB gzip'ed text file of building log (step 2 to 6). I have replaced my actual path by
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.
|Command File||Makefile Goal||Operation|
|removes C compiler files, then performs
It seems that by default the different packages do not search the headers at the same locations. This requires to copy headers from one location to an other one in order the successive builds success. There is perhaps a setting which would remove all these recopies, but I did not find it.
I did not succeed in building it. Fortran requires GMP (GNU Multiple Precision Arithmetic Library) and MPFR (multiple-precision floating-point computations with exact rounding). I have built GMP 4.1.4, with its embbedded MPFR. However, it is advised to build separately the last release (2.2.0) of MPFR. I did not succeed in building this release, even after having applied all the patches. The configure script hangs because it tries to link the
/usr/local/i386-linux-4.0.2/lib/crt1.o i386 Linux object file using Mac OS X gcc. I have not found a patch for solving this.
So I have tried to built Fortran 95 compiler using GMP 4.1.4, with its embbedded MPFR. But building fails after 5 minutes on a link error: it can't find
_stdout. I did not find any patch for solving that.
For all these reasons, I gave up incorporating FORTRAN in the package.
Ada needs GNATS. I have successfully downloaded and built gnats 4.1.0, but I could not conclude the GCC configuration for building Ada.
Approximative durations of build steps, for an iMac G5 1,8 GHz:
|1||download tarballs (89.1 MB)||29' at 55kB/s|
|4||Mac OS X tools||11'|
|6||C++ Compiler Only||25'|
|6||C++, Java and Objective-C Compilers||1h 10'|
This step downloads the tarballs and puts them in the
tarballs directory. If they are already present, this step does nothing. Downloads are performed with
curl line command tool and use
|Note that if you access the
binutils is very easy: configure them, build them and install them succeeded at the first attempt. Configure parameters are
--prefix=/usr/local/i386-linux-4.0.2 (the installation path),
--target=i386-linux for defining the target system.
This step is needed as some default Mac OS X tools are not compatible with some
sedis required for glibc, as
sed –versiondoes not work on the default
msgfmtis also required for glibc, and does not exist by default; we install
gettextpackage, which includes
gawkis required for step7.
All tools are installed in
$(MACOSX_TOOLS_PREFIX) directory. The following steps include the
$(MACOSX_TOOLS_PREFIX)/bin path in their
$PATH search path.
I have spent a lot of time for getting correct configure parameters.
This is the final step: building other compilers and their libraries. Default setting builds: C (again), C++, Objective-C and Java.
For building a subset, you can modify
GCC_BUILD_ALL_PARAMETERS variable setting.
I have implemented a three-stage process for the
build_binary_package makefile goal:
PackageMakeras command line tool, for building a package from the
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 two locations:
build_source_disk_image makefile goal just builds DMG files using
hdutil command line tool. Two DMG files are provided, one without source tarballs, the other with the tarballs. This is the way I distribute the source packages.
For this release, I have used XCode 2.4.1.
Use a case-sensitive file system (see above).
With XCode 2.4.1, PackageMaker 2.1.1 (123) is provided. This release handles relative pathes. I have modified the
i386-linux-gcc-for-mac-binaries.pmproj file so that it uses now only relative pathes, making obsolete path adjustments.
This release builds Intel binaries on an Intel Mac, and ppc binaries on a PowerPC Mac. I do not plan to provide universal binaries.
|Build log on an Intel Mac||i386_linux_gcc_4_1_1_for_intel_mac.log.txt.zip (495.6 KB)|
|Build log on a PPC Mac||i386_linux_gcc_4_1_1_for_ppc_mac.log.txt.zip (496.9 KB)|