15.8.2010 2:46, Max S. kirjoitti:
So... I've been for several days now, attempting to build a cross
compiler for an sh4-linux arch from a laptop with
x86_64-unknown-linux-gnu.
On May 20 this year I seem to have built 4 cross GCCs, 4.1.2 - 4.4.4,
for the 'sh4-linux-gnu' target in 2 hours...
[root@localhost bin]# ls -l -t gcc-sh4-linux*
-rwxr-xr-x 1 root root 176688 20. touko 12:56 gcc-sh4-linux-gnu-4.4
-rwxr-xr-x 1 root root 169308 20. touko 12:52 gcc-sh4-linux-gnu-4.3
-rwxr-xr-x 1 root root 98216 20. touko 11:04 gcc-sh4-linux-gnu-4.1
-rwxr-xr-x 1 root root 157244 20. touko 10:59 gcc-sh4-linux-gnu-4.2
And my build PC was only with AMD Duron 750 MHz and 512 MB... Quick
enough for a slow old dude like me...
Not a Canadian cross or anything that special. just a version of gcc
that runs on my laptop and produces executables for my
hico7760(sh4-linux).
With this kind of goal you should succeed in less than 15 minutes...
Just to make sure I've understood it right heres what I understand about
building a cross compiler.
step 1) build the binutils
step 2) get linux headers
step 3) build a mini version of gcc
step 4) build the standard libs
step 5) use them to rebuild a full version of gcc
I call this "Code Red", the movie with Tom Cruise and Demi Moore will
tell the meaning: To put stupid recruits to do totally unnecessary
exercises. And after these the results are so bad that the recruits
will have their ears red from all the shouting they received :)
The "Prerequisites" in the GCC Installation docs :
http://gcc.gnu.org/install/prerequisites.html
will tell that a cross compiler will be made in only one build stage :
----------------- clip -------------------
Tools/packages necessary for building GCC
ISO C90 compiler
Necessary to bootstrap GCC, although versions of GCC prior to 3.4
also allow bootstrapping with a traditional (K&R) C compiler.
To build all languages in a cross-compiler or other configuration
where 3-stage bootstrap is not performed, you need to start with an
existing GCC binary (version 2.95 or later) because source code for
language frontends other than C might use GCC extensions.
----------------- clip -------------------
What is not clear in this? A native GCC build will usually use a
3-stage bootstrapping but a cross GCC build will need only one
stage..
The following details these steps as I took them (as far as I got).
* First I downloaded(and unpacked) all sources to /home/dev/src
* that means binutils-2.20,linux-2.6.35,gcc-4.5.1,glibc-2.12.1, and
because I read it was good for embedded devices(and got stuck compiling
glibc) newlib-1.18.0
<snip>
$ ${target}-gcc -v
Using built-in specs.
COLLECT_GCC=sh4-linux-gcc
COLLECT_LTO_WRAPPER=/home/dev/toolchain/libexec/gcc/sh4-linux/4.5.1/lto-wrapper
Target: sh4-linux
Configured with: ../gcc-4.5.1/configure --prefix=/home/dev/toolchain
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=sh4-linux --disable-nls --disable-multilib --disable-shared
--disable-threads --enable-languages=c
Thread model: single
gcc version 4.5.1 (GCC)
* I can not however build the simplest of programs. (libs are
missing... naturally... they have not been compiled)
* the idea would then be to build glibc
In a normal case the idea would be to NOT build the target C library!
The target C library of course will be provided by the target system.
"If it ain't broken, don't fix it!" What is the problem with the
target glibc for your "hico7760(sh4-linux)" system?
It can't honestly be that hard to build a cross compiler.
I must be doing something or other wrong.
Can a smith use a pre-made hammer when making a hammer? Can a GCC
builder use a pre-made GCC when making a GCC? Use pre-made native
binutils, bash, glibc,... in a native GCC build? Use the pre-made
target glibc in a $sysroot in a cross GCC build?
"Yes, we can!" is my thought and therefore I will always have my
own builds being easy as a pie. With an attitude "No, we are not
allowed to do these things!" one's life will be really hard :(
Someone who would like to try a cross GCC for 'sh4-linux-gnu' "just
for a fun", is expected to use steps like :
1. get the binutils and GCC sources
2. get the glibc and kernel headers for 'sh4-linux-gnu' from some
Linux/SH4 distro on the net, for instance:
http://ms-n.org/SH-Linux/fc8-shlinux/RPMS/sh4/
3. unpack the glibc and kernel headers RPMS into the chosen $sysroot
4. configure the binutils and GCC sources using the option
'--with-sysroot=$sysroot' to point to the base target C library
5. build binutils and GCC as binaries for the $host and targeting
to the $target and then install them.
With a modern 3 GHz or such PC one could succeed in less than 15
minutes...
After one has a "working" toolchain - it succeeds to compile and
link apps to the $target, in the previous "Fedora Linux 8 for SH4"
- one could think to replace the "temporary" glibc with a self-made
newer glibc. "Just for a fun" with this too... With a fully working
GCC (the prerequisite?) the glibc build should work ok! I remember
that a native build is the expectation in glibc too, not only in
GCC (with "system targets", with "embedded targets" without a
native GCC possibility the default is a cross build).
With some existing "custom" Linux target, having its own installed
glibc runtimes on the target system, one of course MUST use the
"C library for the target" in the crosscompiler too, NEVER replace
it with anything "self-made" ! Neither do this in a native GCC
build!
Or: one can use a different C library from the one on the target
in a crosstoolchain but then one must know what it means and why
one does this... For instance when one wants to produce apps which
should work on Fedora 8 - 12 and newer, one probably uses a glibc
made for Fedora 8 in the crosstoolchain but the main target may be
the newest Fedora 12, but some apps sometimes will be run on 8 - 11
too...
