As a part of my DXR project work I will have to cross-compile Firefox for Mac and Windows on a Linux box.
I’m going to start with a Mac build and follow instructions in this blog post in my attempt to build it.
I need to get toolwhip source code and compile cctools and ld64. These are the parts of a custom toolchain. To spice things up I will also need Apple’s gcc.
I will start with cctools following instructions in cctools.README.
To compile cctools:
CC="gcc -m32 -std=gnu99" CFLAGS="-O2" make -f Makefile.linux
And it fails:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
Google tells me that I need to install glibc-devel package:
yum -y install glibc-devel
Second try:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.3.2/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
That is great. Linker doesn’t like libgcc_s.so for some reason.
A-smarter-than-me-person-over-on-fedora-forums notes that this problem has something to do with compiling 32-bit app on a 64-bit system and suggests that installing GCC compatibility packages compat-libstdc++-33 and compat-libstdc++-296 should help.
I do not know if this is the case. It looks like I would need to do a lot of extra work on a 64-bit box.
“If the mountain won’t come to Muhammad, Muhammad must go to the mountain.”
I’m going to move to 32-bit box.
I’m back to compiling cctools; this time on a 32-bit box. And… it compiles just fine. Now I need to install it. I created some folders, symbolic links, and a script as described in cctools.README under installation.
I have no idea if it’s working or not. Or if I did everything right. But I’m just going to live with it by now.
Next step is to compile and install ld64. I’m going to follow instructions in ld64.README.
To compile ld64:
CC="gcc -m32 -std=gnu99" CXX="g++ -m32" CFLAGS="-O2" CXXFLAGS="${CFLAGS}" make -f Makefile.linux
And it fails. It cannot find declaration of functions like fopen() which is a part of stdio.h.
This does not make any sense. (Edit: It might be related to gcc 4.4.x bug)
Ok, nevermind. I added the following line to /toolwhip-read-only/ld64/src/Options.cpp:
#include <stdio.h>
I feel as if I’m fixing my first assignment in IPC144.
This time around Options.cpp compiled fine, but they might have a 1000 + 1 file with similar problems. Did I mention that I like inflicting pain on myself?
I did the same to:
MachOReaderDylib.hpp
MachOWriterExecutable.hpp
MachOReaderRelocatable.hpp
Ok, the linker compiled. And I created some folders and links mentioned in ld64.README under installation.
By the way, I have revision 176 of toolwhip. And I compile it with gcc 4.4.2.
The next and hopefully the last step to get this toolchain done is Apple’s gcc. I will work on it later.
I’m too exhausted
To write any “Haiku” right now
Do not even start
Donwload Apple’s gcc to toolwip directory and patch it:
wget http://www.opensource.apple.com/tarballs/gcc_42/gcc_42-5574.tar.gz
tar -xvzf gcc_42-5574.tar.gz
patch -p0 --verbose -i gcc_42-5574.patch
To install it, I’m going to follow gcc_42-5574.README.
The first thing I need is “appropriate” Mac SDKs. I’m not a Mac user. And I don’t have Mac to copy SDKs from. So, I wonder which one is appropriate?
It seems that there are two ways to do it: the easy way and the hard way. The easy way consists of bribing a friendly Mac user to get you a copy of /Developer/SDKs/MacOSX10.5.sdk folder. The hard way consists of downloading XCode and getting necessary packages from there.
Since I said earlier that I like inflicting pain on myself, I will go with the hard way.
There are a couple of way to open .dmg files.
- To open “f****** stupid useless .dmg file” in Linux
- To open .dmg file in Windows
- HFSExplorer for both
Once that’s done, all packages can be found under… package folder. I’m going to make a wild guess and say that MacOSX10.5.pkg is the package I need. However, now I’m stuck with “f****** stupid useless .pkg file”. And after long search I found nothing (that actually works) on how to unpack .pkg files outside Mac. (I’m almost waiting for someone to point out, that it’s something simple and obvious).
That leaves me no choice, but to go the easy way:
beer -h friendlyMacUser -o MacOSX10.5.sdk.gz
And time to build it.
First problem:
P: lipo: can't open input file: /usr/lib/libSystem.B.dylib (No such file or directory)
It’s looking for this library in the standard folder.
S: ln -s /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libSystem.B.dylib /usr/lib/libSystem.B.dylib
Second problem:
make[3]: execvp: i686-apple-darwin9-ranlib: Permission denied
I’m doing everything as root. However,i686-apple-darwin9-ranlib is a script I created earlier (see cctools.README). And the error has everything to do with a permission of the script.
chmod +x /Developer/usr/bin/i686-apple-darwin9-ranlib
Third problem:
ld warning: in /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libc.dylib, file is not of required architecture
A long list of missing references...
This is 9/10 bad on my scale of Bad, because it has everything to do with the MacOSX10.5.sdk files I got from a random Mac.
Below is the content of libc.dylib:
XSym
0015
8ddc754cd3d0fce1cdf43a87f3e54bca
libSystem.dylib
It looks like it points to libSystem.dylib, which, in turn, points to libSystem.B.dylib. And libSystem.B.dylib is compiled library.
I think I will have to review build log, find any reference of libSystem.B.dylib, see what objects libSystem.B.dylib is compiled from, and check their source code. Or I can just use nm, but this is a Mac library, so it might not work. So, by doing this, I might find out what “architercute” it supports, and what I’m doing wrong.
It figures that nm doesn’t work after all. It cannot recognize “dylib” files. So, the only way is to check the build log.
