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...
