I've managed to compile the GNU toolchain on my ARM Linux box, following
Chris Rutter's guide. I encountered a few problems along the way, and I'll
give the details here in case anyone finds them useful, and so that maybe
Chris can incorporate them into his guide.
Compiling binutils (2.9.1.0.19a) was without incident.
For egcs (1.1.2 + arm-diff-990325) I used patches to a version from a Debian
2.1 source CD to save on downloading. I found I had to move the `p'
directory out of the egcs dir because the Pascal compiler wouldn't compile
(it wanted to be compiled by a different version of gcc). I also had to
install autoconf and m4 (since I was using an up-patched version,
presumably).
glibc (2.1) was trickier. It needed a newer make than Russell's
distribution has. To compile, make wanted `ar.h', which wasn't present, so
I copied it from another Linux box.
I used the 2.0.36 kernel headers to compile; these don't define
__NR__sysctl, which glibc's sysdeps/unix/sysv/linux/sysctl.c refers to. I
copied the definition from a 2.2.x header into 2.0.36's
linux/include/asm-arm/unistd.h to solve this. The glibc FAQ and Chris's
guide say that glibc will compile with either 2.0 or 2.2 headers, but this
is not true for the ARM without this change, it seems.
I had to run `ranlib' on a file (but I'd seen this mentioned on this list
before).
`ld' runs out of memory when linking various libraries. I fixed this by
relinking `ld' statically.
When it got to linking glibc's various executables (like db2/makedb), it
failed with unresolved references to symbols mostly of the form `_db_*'. At
this point, I could do `make install' and the libraries would get installed
and I could try compiling a hello world program. That gave the same
unresolved references unless I explicitly told arm-linux-gcc to link with
the newly-built libc.so, which then just gave `__libc_global_ctors' as
unresolved. I forced a recompilation of the file that defines this
(elf/soinit.c), after which the unresolved symbols stopped. This was a bit
odd, but I suspect it had something to do with things getting built in an
unusual order (I had ran `make -k' a few times).
My remaining problem was that, after compiling and linking a hellow prog, it
expected ld-linux.so.2 to be in /lib rather than /usr/arm-new/lib where it's
been installed. Is this correct behaviour? It's easily fixed, anyway
(either by linking the file across or using
``-Wl,-dynamic-linker=/usr/arm-new/lib/ld-linux.so.2'').
Also, running ldd on my newly-made hellow ELF executable (or the executables
that glibc builds) dies with a register dump. Not an immediate problem.
Incidentally, Debian appears to use a separate ld.so from the one in glibc.
Why's that?
--
Mark Seaborn
- [EMAIL PROTECTED] - http://www.argonet.co.uk/users/mseaborn/ -
``If it stays as it is I can't see it altering''
-- Graham Taylor
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
