gcc 4.3.5 on old Quadra 700 (25 MHz 68040)

[Kai Ruottu]

14.4.2011 18:23, kevin diggs kirjoitti:
> Hi,
>
> On Thu, Apr 14, 2011 at 3:00 AM, Kai Ruottu<kai.ruottu@wippies.com>  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 :(