An OS X 10.5 -> *-linux-gnu HOWTO, and a help req.

[Joseph Fannin <jfannin at gmail dot com>]

Hi!

I've successfully built a cross toolchain on OS X 10.5 Leopard
targeting powerpc-linux-gnu using the crosstool scripts; I've had less
luck building a working compiler on the same machine targeting
x86-linux-gnu, which is a bit of a surprise.  I'm writing to share I
how I got this to work, and maybe solicit some insight into the
problem with the x86 compiler.

This message has gotten a bit long, but I hope it'll be useful to
anyone who is unfamiliar with all this like me.

I'm working on this because I'd like to use my MacBook (an x86 Mac) as
a distcc host for compiling the Linux kernel without rebooting the
laptop into Linux.  I've built a kernel over distcc using the powerpc
compiler that now has an uptime of three days on my old PowerMac,
so it seems to work.  I'll get into the x86 thing in a minute.

The powerpc toolchain I built is gcc 4.1.0, glibc 2.3.6-tls, binutils
2.16.1, i.e. the default in the crosstool scripts.

I used MacPorts to install some of the dependencies I needed to to
build the toolchain.  First I installed another compiler out of
MacPorts, gcc v4.2.  I did this because the toolchain that Apple ships
creates a "bundle" when passed the -g flag that presumably contains
debugging information
(e.g. conftest.dSYM/Contents/Resources/DWARF/conftest) that made
autoconf scripts fail due to stray files lying around (rm -f conftest*
won't remove the directory).

Reading the autoconf scripts, I wasn't sure the extra directory
wouldn't sometimes result in autoconf testing the bundle directory
rather than the output file it expected and getting false results, so
I just installed another compiler.

I then had to hack the crosstool.sh script in two places where it
explicitly set CC=gcc, overridding the CC variable I'd set in the
environment.

I also installed MPFR and GMP via MacPorts -- GMP, at least, seems to
be required -- and set CPPFLAGS and LDFLAGS so they got picked up --
i.e. I ended up invoking crosstool with:

CC="gcc-mp-4.2 CPPFLAGS="-I/opt/local/include" \
LDFLAGS="-L/opt/local/lib" ./demo-powerpc-750.sh"

There are a couple of issues that pop up during the build which I fixed
up in place rather than making proper patches for.  I added
"--no-build" to the eval statement in demo-powerpc-750.sh so I could
make the changes, then removed that option and replaced it with
"--no-unpack" so my changes didn't get clobbered.

The two places that can be fixed up before the build starts are the
glibc configure script and the gprof directory of binutils.

The glibc configure script tests for as and ld with a full path it
must have gotten from somewhere, and doesn't like the versions of
those tools.  Because of the full pathnames, the wrapper scripts
discussed in the crosstool HOWTO don't seem to work, even if they're
first in the PATH.

So I added "ac_verc_fail=no" on a line by itself between the
assignment of that variable and the test for it.  I did this for both
AS and LD -- searching for "Found it" in a text editor jumps right to
the relevant areas -- they're the first two in the version of glibc I
used.

The thing with gprof seems to be that Apple's make gets confused by a
few files with a .m extension in there -- I read that it expects them
to contain Objective-C, and prefer them to .c files.  I simple deleted
them from the gprof directory under the unpacked binutils dir -- I
don't know if this affects the resulting gprof binary but I don't seem
to need it.  With those files removed the build moves on.

The last issue can't be fixed in place until the build has been
working, so I just let the build error out, fixed the file, and
restarted the build.  The file is build-glibc/csu/version-info.h .
In that file it's necessary to make sure every line has a beginning-
and end-quote, rather than allow the quotes to remain open onto the
next line.

And that was it, IIRC.  I haven't tested the toolchain on the local
host, but I installed distcc out of MacPorts, got LaunchDaemon to
start it, made some symlinks so distcc could find it as
'powerpc-linux-gnu-*", and started using the MacBook as a distcc host
to build kernels.

----

But going through the same steps with x86 produces a toolchain that
doesn't work.  Shooting in the dark, I've tried glibc-2.3.6 and
-2.3.5, targetted i486-linux-gnu rather than i686-unknown-linux-gnu
(which is what I really want anyway), disabled the --march= and --tune
options (had to pass --disable-__thread to glibc here, but this is
again what I really want.  I only really want to compile kernel C
anyway).

I'm trying to stick with gcc-4.1, since that's the version of the
compilers on the other distcc hosts.

When I try to build the kernel, the compiler emits things like:

mm/bootmem.c:125: warning: asm operand 0 probably doesn't match constraints
mm/bootmem.c:126: warning: asm operand 0 probably doesn't match constraints
mm/bootmem.c:124: error: impossible constraint in 'asm'
mm/bootmem.c:125: error: impossible constraint in 'asm'
mm/bootmem.c:126: error: impossible constraint in 'asm'

... and:

{standard input}:6:Expected comma after segment-name
{standard input}:6:Rest of line ignored. 1st junk character valued 32 ( ).
{standard input}:34:Expected comma after segment-name
{standard input}:34:Rest of line ignored. 1st junk character valued 32 ( ).
{standard input}:67:Rest of line ignored. 1st junk character valued 102 (f).
{standard input}:68:Unknown pseudo-op: .previous
{standard input}:69:Spurious digit 6.
{standard input}:69:Rest of line ignored. 1st junk character valued 54 (6)

Some googling suggests that this is a problem with the assembler,
possibly that it doesn't understand ELF.  I'm not sure how to test for
this, but I'll probably try some of the tests in crosstool to see if I
don't get some more illuminating errors.  The assembler identifies
itself as targeting i486-linux-gnu.

The line of thought I've been following is that maybe the binutils
build scripts are getting confused about the target's object format,
possibly as a result of using Apples as to build it.  I've tried
passing --with-gnu-as=no to binutils' configure script, but that just
causes configure to refuse to build gas.  There doesn't seem to be a
port of gas to OS X that I could build either.

If anyone has any theories about what's going on here, I'd love to
hear it.  I expected to have trouble with the powerpc cross toolchain,
not the x86 one -- maybe it has something to do with the x86 toolchain
not being a "true" cross-compiler, being that it's built and run on an
x86?

--
Joseph Fannin
jfannin@gmail.com


--
For unsubscribe information see http://sourceware.org/lists.html#faq