David Daney wrote:
Ian Lance Taylor writes:
> Jonathan Day <[EMAIL PROTECTED]> writes:
> > > My question is simple enough - has anyone built a
> > toolchain for a MIPS64-Linux-GNU target?
> > Yes, I did, last year.
> > But I did it through a tedious iterative process--build the
binutils,
> build the compiler until it fails building libgcc, install parts of
> it, build glibc enough to install the header files (with the kernel
> header files there too), build the rest of the compiler, build the
> rest of glibc. Various things broke along the way and needed
> patching. I think it took me about a week, interspersed with other
> things.
My 'from scratch' method was quite the same a year or two again. So
when trying to update last July I already had some 'mips64-linux-gnu'
headers and libraries and could use them when updating the GCCs...
Dan Kegel's crosstool does it for many different platform/tool version
combinations (or so I have herd). I think the problem is that it (and
other solutions like it) have ad hoc hacks/patches for each combination
to make it work and perhaps that mips64-linux-gnu is not well supported.
How one gets the first toolchain made shouldn't have the importance
many people think it has... My opinion (clashing badly with Dan's) is
that the first build has no importance at all, if one knows the basics
for Linux, for compiling and for other newbie-level things, one easily
succeeds to get the first toolchain. What Ian and I did, is mostly based
on 'trivial' understanding like :
- the headers for 'mips-linux-gnu' can be similar to or even identical
with those for 'mips64-linux-gnu', so if one has the previous, they
are at least a very good starting point for getting the right
headers.
- searching with 'mips64' in the glibc's 'sysdeps' tree quite easily
reveals the few places where there could be some different headers
for 'mips64'
when trying to collect the required "target headers" for the GCC's 'libgcc'
compile. Using '--disable-shared-libgcc' etc. options in the first GCC
build, enables one to succeed in the 'make all-gcc' with the bare target
headers. And lets one to continue with the glibc build...
My estimate for a 'from scratch' build would be 4 hours if one already
has the required glibc version made for some other Linux, but of course
the 'mips' one in the 'mips64' case would be the best. And if one has
the required newbie-level know-how about GCC, compiling and the Linux
glibc components (crt*.o, libc.so.6, libc.so, ld.so.1 etc.). If one
hasn't, one can cause quite the same situation as those Greenpeace
people who put gasoline into the tank in a diesel car and were then
angry when they got no help in solving the mess they had caused with
their total ignoracy... This happened in Finnish Lapland and even the
children here know that using gasoline instead of diesel can be very
dangerous for the engine, or doing vice versa. My experience collected
from the crossgcc list tells that many cross-GCC builders will come to
the roads just as ignorant as the Greenpeacers. They hate cars so why
they would like to learn anything about them? But why the GCC builders
hate GCC, Linux, glibc etc. and therefore don't want to learn anything
about them, has been an eternal mystery for me...
Building from absolute scratch can be a challenge for many, but some
can think: "When At Last You Do Succeed, Never Try Again" and never any
more try that... And start to think if there even is any reason for that
during the first toolchain build. People who build native-GCCs, never
(or very seldom) start from scratch, the target C library is already
installed and one only builds the new binutils and the new GCC when
wanting to produce a "self-made toolchain"... The same idea works also
with cross-GCCs...
If one hasn't the target C library, one can always borrow that or
something... A minimal 'glibc-2.3.5' for 'mips64-linux-gnu' probably
takes 1 - 2 Mbytes as a '.tar.gz' package so anyone who has a direct
net connection and has glibc-2.3.5 made for 'mips64-linux-gnu', can
email pack the base stuff and email it... Including myself. One only
needs to have the right 'lazy' attitude and ask someone to send...
I did similar with mipsel-linux-gnu using headers lifted (and hacked)
from glibc on i686-pc-linux-gnu as a starting point.
There is a definite chicken-and-egg problem here. But once you have a
working toolchain you never suffer from the problem again. The result
is that there is no motivation to solve it once you know enough to fix it.
David seems to have the same "When At Last You Do Succeed, Never Try
Again" attitude which I have...
Okeydokey, I haven't any clue what the 'mips64-linux-gnu' target SHOULD
be... But I know what will be the result when one builds the toolchain
using the current defaults in GNU binutils, GCC and glibc-2.3.5. Let's
start with binutils, the 'ld -V' may show :
GNU ld version 2.16.91.0.1 20050622
Supported emulations:
elf32btsmipn32
elf32ltsmipn32
elf32btsmip
elf32ltsmip
elf64btsmip
elf64ltsmip
and immediately one sees the 32-bit 'n32' being the default, not the
64-bit one. The produced GCC maybe produces 64-bit as default but the
produced glibc-2.3.5 has the '-mabi=n32' used as default when producing
it, so the default 'libc.so.6' tells with 'readelf -h' :
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x153a4
Start of program headers: 52 (bytes into file)
Start of section headers: 1347072 (bytes into file)
Flags: 0x20000027, noreorder, pic, cpic,
abi2, mips3
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 82
Section header string table index: 79
The 'mips3' flag is there so it must be for the R4000 AFAIK... And the
produced default glibc-2.3.5 will be installed into '.../lib32' and
'.../usr/lib32', not to the expected '.../lib64' and '.../usr/lib64',
which is the case with other '*64-linux-gnu' targets...
I used gcc-3.4.4 to build glibc-2.3.5 for the 'mips64-linux-gnu' but
produced also gcc-4.0.1 as another GCC for this target. Cannot remember
any problems in the glibc build, neither in those GCC builds... But as
I told, my toolchain was built using the current defaults in the GNU
sources and for 'mips64-linux-gnu' the default object format is now that
got using '-mabi=n32' for the compiler(s), not the 64-bit one...
So, Jonathan, if you need to get a knife (glibc) for producing your
own hammer (gcc), just ask someone to give that knife and produce your
own hammer first with that borrowed knife. And then produce your own
knife using your self-made hammer and later the final hammer with your
self-made knife... After customizing your hammer and knife many times
you soon forget how on earth you managed to get the first hammer and
knife and what the heck, who even cares about that !
If you then find out what your final object format will be...
David Daney
