14.4.2011 18:23, kevin diggs kirjoitti:
Hi,
On Thu, Apr 14, 2011 at 3:00 AM, Kai Ruottu<kai.ruottu@xxxxxxxxxxx> wrote:
You mean "native build" ? As you can see from the previous
time stamps, the time between the 3.4.6 and 4.1.2 installs
was about 15 minutes, so doing it cross could be much, much
more sane!
A native 4.3.5 build on a 650 MHz pentium3 took 5.5 hours for
bootstrap of c and c++. The same build for 3.4.6 took under an hour.
Hmmm, totally three GCCs will be built in a native GCC bootstrap
so these times could be divided by 2-3...
Maybe my 15 minutes time difference only meaned that the second
was installed 15 minutes later... Building/installing two GCC
versions for the same target at the same time isn't that odd...
Probably it took 30-60 minutes for the gcc-4.3.5 build to get
to the "crash" phase... For gcc-3.4.6 and 4.1.2 a 15 minutes
build time doesn't sound that insane with the 750MHz/768MB RAM
PC I used.
An idle 700 chews up about 61 watts. But it will take a week or so to
complete. That is 10 KWH.
So ...
Can someone point me to some info to learn how to setup cross
compilers? Is it a little easier if I am just building the compiler
itself?
Maybe most instructions in net are misleading because their goal
no more is an existing target system but a totally unexisting (in
the beginning) "from scratch" system - one aims to build the whole
target system and getting a crosstoolchain for it is the first step
in the process. Why people no more need crosstoolchains for cross-
compiling to other existing target systems is really odd...
But producing a crosstoolchain for an existing target system is
nowadays very easy process with simple steps :
1. choose a suitable $sysroot where to unpack/copy the target C
library etc. In NetBSD-case unpacking the 'base.tgz' and 'comp.tgz'
packages for the right target would be most easy. My own choice
for NetBSD1.6.1/mac68k $sysroot was '/opt/host-NetBSD1.6.1_mac68k'
2. produce GNU binutils for the $target, using the options :
--prefix=$prefix --target=$target --with-sysroot=$sysroot
in configure. If there is no '--prefix=' option, '/usr/local'
will be the $prefix for the binutils binaries to install, into
'$prefix/bin' and '$prefix/$target/bin'. The '--with-sysroot='
only tells for 'ld' where the alien $target stuff is. If one wants to
use one's own $prefix, maybe '/opt/cross', '/opt/gnu', '/opt/gcc'
could be suitable choices for the $prefix. The aim really is
that one would always use the same $prefix altough one would
build 100 crosstoolchains for 100 different targets, they all
should work and not disturb each others.
3. produce GNU GCC for the $target, using the options :
--prefix=$prefix --target=$target --with-sysroot=$sysroot
in configure, maybe some target specific ones too. If there
is no '--prefix=' option, '/usr/local' will be the $prefix
for the GCC binaries to install, into '$prefix/bin',
'$prefix/$target', $prefix/lib/gcc/$target/$gcc-version' and
'$prefix/libexec/gcc/$target/$gcc-version'. The '--with-sysroot='
only tells where the alien $target stuff is. Of course one
must use exactly same $prefix, $target and $sysroot values
for both binutils and GCC! Changing them really happens as
if GCC could find the '$target-as' and '$target-ld' automatically
if they only are in a $PATH directory, GCC really searches
'as' and 'ld' first from its own directories, then from $PATH
If it only finds the native 'as' and 'ld', that's not good :(
The '--build=$build' and '--host=$host' should be guessed right
via the 'config.guess' script, usually as the build host...
The current "gcc-4.1.3 20080704 prerelease (NetBSD nb2 20081120)" for
NetBSD 5.1/mac68k seems to been configured with :
/usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long
--disable-multilib --enable-threads --disable-symvers
--build=x86_64-unknown-netbsd4.99.72 --host=m68k--netbsdelf
--target=m68k--netbsdelf --enable-__cxa_atexit
Here some target specific GCC configure options can be seen and
all the three '--build=', '--host=' and '--target=' were specified.
The product really was a native GCC for the $target system after
the "stage1" cross GCC for the $build system...
My cross gcc-4.1.2 was configures like :
[root@localhost lib]# gcc-m68k-netbsd1.6.1-4.1 -v
Using built-in specs.
Target: m68k-netbsdelf1.6.1
Configured with: ../configure --build=i686-linux-gnu
--host=i686-linux-gnu --target=m68k-netbsdelf1.6.1
--enable-languages=c,c++ --libexecdir=/usr/local/lib
--enable-shared=libstdc++ --disable-threads --disable-nls
--enable-version-specific-runtime-libs
--with-sysroot=/opt/host-NetBSD1.6.1_mac68k
--with-gxx-include-dir=/usr/local/include/c++/4.1.2 --with-pkgversion=by
Kai Ruottu 2011q1 --program-suffix=-m68k-netbsd1.6.1-4.1
Thread model: single
gcc version 4.1.2
The '--with-pkgversion=' had no influence with gcc-4.1.2 yet, I don't
know why I had the '--disable-threads', doesn't the NetBSD 1.6.1
C library/headers support them?. One really must know the target
specifics too...
With these instructions you should get started or succeed immediately!
Some "cleaning" in the '$sysroot/usr/lib' could though be required, I
saw the gcc-2.95.2 or something native GCC 'libstdc++' parts there :
[root@localhost lib]# ls -l libstdc++*
-r--r--r-- 1 root wheel 409582 8. huhti 2003 libstdc++.a
-r--r--r-- 1 root wheel 468470 8. huhti 2003 libstdc++_p.a
-r--r--r-- 1 root wheel 410716 8. huhti 2003 libstdc++_pic.a
lrwxrwxrwx 1 root wheel 16 28. helmi 17:48 libstdc++.so ->
libstdc++.so.4.0
lrwxrwxrwx 1 root wheel 16 28. helmi 17:48 libstdc++.so.4 ->
libstdc++.so.4.0
-r--r--r-- 1 root wheel 340050 8. huhti 2003 libstdc++.so.4.0
The 'base.tgz' includes quite much unnecessary stuff, not only the
shared C libraries :(
