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://sourcewar
e.org/lists.html#faq
|