Updating powerpc-crosscompile environment from gcc-2.95.3

[Kai Ruottu]

Frank Beesley wrote:
> 
> Lets take one step back - take a look at Kimmo Mustonen's original message:
> 
> .../gcc-4.0.2/configure --target=powerpc-linux --with-cpu=603e --nfp \
>    --prefix=/tmp/cross --enable-shared --enable-languages="c" \
>    --with-newlib --disable-threads

Here we have all kind of "my friend told this could be good to be
there"-like things, just as people used to put all kind of things
into their CONFIG.SYS and AUTOEXEC.BAT in the good old DOS time...
For instance the '--with-newlib' has absolutely nothing to do with
a Linux targeted GCC configuration.

Linux/PPC is finally quite used system, there are distros like SuSE
Linux 10.0/ppc, YellowDog 4.0 (or newer), Fedora Core 3/PPC, Debian
and maybe many others Linux/PPC:s freely available and downloadable.
So starting from absolute scratch this way has its only motivation
in those bolshevism-like ideas, forgotting everything created this
far and starting everything from the very beginning. There really
isn't any lack of available bootstrap components for Linux/PPC.

As this example shows, the GCC build tries to produce the
'libgcc_s.so.1' by linking against the already available target C
library, and tries to link simple dummy stubs when configuring the
extra libiberty and libstdc++-v3 components. Unless one disables
producing the shared libraries. And requires the target headers from
the C library when compiling the exception handling routines into
the 'libgcc_eh.a'... If one has "some suitable" target C library,
the '--enable-shared --enable-threads' can be used, otherwise both
must be disabled and the result is a stripped GCC which maybe can
or can not compile the C library ok. One cannot be sure about this
without very deep understanding about the C library doings...

> So we both have just built and installed a new binutils (2.16 for Kimmo, 
> 2.15 for me) using a native gcc (2.95 for Kimmo, 3.2.2 for me) and we 
> are now trying to build the first-stage gcc cross-compiler (4.0.2 for 
> Kimmo, 4.0.1 for me). My suggestion to Kimmo was to change his gcc 
> configure to remove enable-shared and replace it with disable-shared. 
> Because of this change I am able to get further through the first-step 
> gcc cross-compiler build - though is does not successfully complete.

As told, the usability of this kind of 'stripped GCC' is not so clear...
Anyway I tried this with 'ppc-linux' and got the GCC parts made but
without the 'libgcc_eh.a'. And then got glibc-2.3.5 almost made without
any extra workarounds. The missing 'libgcc_eh.a' required one and during
the 'make install' the 'dlfcn/libdl.so.2' was told to be missing, so one
workaround more was needed... I produced stripped GCCs from the
unmodified FSF gcc-3.4.4 and gcc-4.0.2 sources and used gcc-3.4.4 to
compile the glibc-2.3.5, with the linux-2.6.12.2 kernel headers..

As the alternative I would recommend to everyone in these "bootstrap"
cases when there are no self-made components yet, is to use pre-made
bootstrap-components. When producing a native GCC people mostly accept
a pre-made GCC, pre-made binutils and pre-made glibc for the native
target. Only very few try to avoid using them and are therefore obliged
to cross-produce these on some non-GNU system which has absolutely no
pre-made GNU components, so that one can produce everything from their
virgin sources. With a cross-GCC the only required bootstrap component
is the "suitable" target C library because the GCC build wants it in
order to produce that 'libgcc_s.so.1', the threads and the exception
handling support. When the 'complete' stage1 GCC is ready, it can be
used to compile the C library. Using this kind of GCC there shouldn't
be any troubles and required workarounds at all...

I re-made the gcc-3.4.4 using the SuSE Linux 10.0 glibc-2.3.5-40 RPMS
(the 'base shared' and the 'devel') as the target C library and built
both C and C++ support immediately, including libiberty and libstdc++.
And then tried this complete GCC with the glibc-2.3.5 sources and with
the linux-2.6.12.2 kernel headers. Now the build went through without
any problems. But I didn't (yet) try installing it, so the problem
with the missing 'libdl.so.2' could have existed still... Even with a
'just for a fun' crosstoolchain like this, I prefer to know what the
target system is, so it producing code which should run ok on SuSE 10.0
is better than it producing code for something which doesn't exist, a
'generic Linux/PPC using generic glibc-2.3.5'...

> After I run the gcc configure I run make to build the gcc cross 
> compiler. This is what is failing with the message that it cannot create 
> executables - this is from within the make script, and yes I understand 
> that the "compiler" is not who actually makes the "executable".

  Maybe you don't try to produce only GCC but also libiberty and
libstdc++, which then require the C library to exist... I would
be quite sure that the GCC build ('make all-gcc') doesn't try to
create any executables with the produced crosscompiler ! If this
happens during the GCC build in the 'gcc' subdirectory, please
tell where !

 > I have
> also tried setting my path to $PREFIX/$TARGET/bin:$PATH to point at the 
> newly built tools but the configure for gcc fails when I do this. So 
> still have not figured out the right combination to build the gcc cross 
> compiler. I cannot successfully run "make install-gcc" because I cannot 
> build gcc for the powerpc-motorola-linux target.

  For this I can only say that using the "build & install only GCC"
commands:

     make all-gcc
     make install-gcc

should work after using the '--disable-shared --disable-threads' options
during the GCC configure... The gcc-4.0.2 and gcc-3.4.4 sources allowed
building them without any headers from the C library. But older '3.x'
GCCs can require some Linux target headers from glibc with Linux/PPC...