Re: Updating powerpc-crosscompile environment from gcc-2.95.3

Re: Updating powerpc-crosscompile environment from gcc-2.95.3

[Frank Beesley]

Kimmo,

I am trying something very similar. I am trying to use binutils-2.15, 
gcc  gcc-4.0.1, glibc-2.3.5 all for the Freescale MPC5200 (603e core).

Your config:
../gcc-4.0.2/configure --target=powerpc-linux --with-cpu=603e --nfp 
--prefix=/tmp/cross --enable-shared --enable-languages="c" --with-newlib 
--disable-threads

--> try --disable-shared because on the first gcc build you do not yet 
have libraries to share.


My config:
PREFIX=/opt/ppc
TARGET=powerpc-motorola-linux
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:$PREFIX/bin

"../gcc-4.0.1/configure --prefix=$PREFIX --target=$TARGET --disable-nls 
--disable-shared --enable-languages=c --without-headers --with-newlib"

"make"

I get farther then the message you have but it still fails with:
checking for powerpc-motorola-linux-gcc...  /rpm/ppc/build/gcc/gcc/xgcc 
-B/rpm/ppc/build/gcc/gcc/ -B/opt/ppc/powerpc-motorola-linux/bin/ 
-B/opt/ppc/powerpc-motorola-linux/lib/ -isystem 
/opt/ppc/powerpc-motorola-linux/include -isystem 
/opt/ppc/powerpc-motorola-linux/sys-include
checking for C compiler default output file name... configure: error: C 
compiler cannot create executables

Note:
- I do have logs if anyone wants to see them.
- I have also added the "--with-cpu=603e" option and get the same error.

Frank Beesley

Re: Updating powerpc-crosscompile environment from gcc-2.95.3

[Kai Ruottu]

Frank Beesley wrote:

> "../gcc-4.0.1/configure --prefix=$PREFIX --target=$TARGET --disable-nls 
> --disable-shared --enable-languages=c --without-headers --with-newlib"
> 
> "make"
> 
> I get farther then the message you have but it still fails with:
> checking for powerpc-motorola-linux-gcc...  /rpm/ppc/build/gcc/gcc/xgcc 
> -B/rpm/ppc/build/gcc/gcc/ -B/opt/ppc/powerpc-motorola-linux/bin/ 
> -B/opt/ppc/powerpc-motorola-linux/lib/ -isystem 
> /opt/ppc/powerpc-motorola-linux/include -isystem 
> /opt/ppc/powerpc-motorola-linux/sys-include
> checking for C compiler default output file name... configure: error: C 
> compiler cannot create executables

  What do you think being required for "creating executables" ?  If you
know this quite basic thing about "C compilers", then you also know why
it cannot create them !

  In the GCC world, "creating executables" is very far from "compiling",
but in the Windoze MSVC, BCC etc. cases "compiling" is considered being
just the same thing as "creating executables" !

  So, believe me or not, this error message is really misleading or just
a fact in the GCC world: A "C compiler" never creates executables there,
it doesn't even "create objects", one needs an assembler from the GNU
binutils or some "native 'as'" for this task... What kind of tool
creates executables and what kind of components will be required
additionally with the "compiled & assembled" object created from the
"hello world" C source, will be leaved to you as a homework to find
out...

  In your case I would try writing :

    make install-gcc

and then try "compiling" a Hello World in order to see what happens:

    powerpc-motorola-linux-gcc -v -O2 -o hello-test hello.c

Can it create this 'hello-test' executable at all?  What very obvious is
still missing

Re: Updating powerpc-crosscompile environment from gcc-2.95.3

[corey taylor]

>   In the GCC world, "creating executables" is very far from "compiling",
> but in the Windoze MSVC, BCC etc. cases "compiling" is considered being
> just the same thing as "creating executables" !

Not entirely true.  You just typically interact with the wrapper
program, but compiling and lnking are distinct processes in msvc..

corey

Re: Updating powerpc-crosscompile environment from gcc-2.95.3

[Kai Ruottu]

corey taylor wrote:
>>  In the GCC world, "creating executables" is very far from "compiling",
>>but in the Windoze MSVC, BCC etc. cases "compiling" is considered being
>>just the same thing as "creating executables" !
> 
> 
> Not entirely true.  You just typically interact with the wrapper
> program, but compiling and lnking are distinct processes in msvc..

  Sad maybe, but GCC doesn't even provide a C library, neither the
binutils. One must get them from somewhere else... That one cannot
just download the "Free GNU C compiler" and then try "compiling"
the "Hello World", maybe is the first lecture people will get about
using GCC... At least it was for me over 10 years ago :-(

Re: Updating powerpc-crosscompile environment from gcc-2.95.3

[Kai Ruottu]

corey taylor wrote:
> Not entirely true.  You just typically interact with the wrapper
> program, but compiling and lnking are distinct processes in msvc..

Oops, my point was to tell that those Windoze compilers I have met,
always have had both binutils and all the standard libraries for
both C and C++. But GCC can come totally alone, without any binutils
and libraries.  A GCC-builder shouldn't expect a "complete compiler"
coming from the 'gcc' subdirectory after it is built !

Re: Updating powerpc-crosscompile environment from gcc-2.95.3

[Frank Beesley]

Lets take one step back - take a look at Kimmo Mustonen's original message:

-------
./configure --target=powerpc-linux --prefix=/tmp/cross --nfp
make TARGET_CONFIGDIRS=
make install
PATH=/tmp/cross/bin:$PATH
export PATH
cd /tmp/cross/src
bzip2 -dc /m/nfs/data/readwrite/sipo-external/gcc-4.0.2.tar.bz2 \
    | tar -xf -
mkdir -p gcc-4.0.2-obj
cd gcc-4.0.2-obj
../gcc-4.0.2/configure --target=powerpc-linux --with-cpu=603e --nfp \
    --prefix=/tmp/cross --enable-shared --enable-languages="c" \
    --with-newlib --disable-threads
make TARGET_CONFIGDIRS=
-------

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.

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

Thanks
Frank




Kai Ruottu wrote:

> Frank Beesley wrote:
>
>> "../gcc-4.0.1/configure --prefix=$PREFIX --target=$TARGET 
>> --disable-nls --disable-shared --enable-languages=c --without-headers 
>> --with-newlib"
>>
>> "make"
>>
>> I get farther then the message you have but it still fails with:
>> checking for powerpc-motorola-linux-gcc...  
>> /rpm/ppc/build/gcc/gcc/xgcc -B/rpm/ppc/build/gcc/gcc/ 
>> -B/opt/ppc/powerpc-motorola-linux/bin/ 
>> -B/opt/ppc/powerpc-motorola-linux/lib/ -isystem 
>> /opt/ppc/powerpc-motorola-linux/include -isystem 
>> /opt/ppc/powerpc-motorola-linux/sys-include
>> checking for C compiler default output file name... configure: error: 
>> C compiler cannot create executables
>
>
>  What do you think being required for "creating executables" ?  If you
> know this quite basic thing about "C compilers", then you also know why
> it cannot create them !
>
>  In the GCC world, "creating executables" is very far from "compiling",
> but in the Windoze MSVC, BCC etc. cases "compiling" is considered being
> just the same thing as "creating executables" !
>
>  So, believe me or not, this error message is really misleading or just
> a fact in the GCC world: A "C compiler" never creates executables there,
> it doesn't even "create objects", one needs an assembler from the GNU
> binutils or some "native 'as'" for this task... What kind of tool
> creates executables and what kind of components will be required
> additionally with the "compiled & assembled" object created from the
> "hello world" C source, will be leaved to you as a homework to find
> out...
>
>  In your case I would try writing :
>
>    make install-gcc
>
> and then try "compiling" a Hello World in order to see what happens:
>
>    powerpc-motorola-linux-gcc -v -O2 -o hello-test hello.c
>
> Can it create this 'hello-test' executable at all?  What very obvious is
> still missing
>

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

Re: Updating powerpc-crosscompile environment from gcc-2.95.3

[Kai Ruottu]

Kai Ruottu wrote:

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

  This can be understood wrong... The last clause was for producing
the 'libgcc_s.so.1' and such, 'libgcc_s-nof.so.1' maybe for the
'soft-float' case in Linux/PPC. Trying to produce libiberty and
libstdc++ will always try to link small dummy stub programs as one
part of their configuration. And so the target C library being
working is obligatory...

  About installing the target C library I can only say that producing
glibc from sources and then installing it with 'make install', isn't
any easier than just unpacking some prebuilt glibc RPMS. Both require
just the same fixes after the base installations. But glibcs taken
from SuSE can be harder than those from Red Hat or Fedora, the SuSE
ones have always had symlinks to the absolute '/lib' when the self-made
and self-installed ones plus at least the Red Hat ones, have relative
symlinks to the '../../lib' from their '/usr/lib'. Not a serious
nuisance after the first install, during it one usually prepares a
script with commands :

    ln -f -s ../../lib/<the_libname_in_lib> <the_libname_here>

to be run in the '/usr/lib' install place, '$sysroot/usr/lib' to fix
those bad symlinks...

Re: Updating powerpc-crosscompile environment from gcc-2.95.3

[Kai Ruottu]

Kai Ruottu wrote:

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

  I forgot to tell that the glibc-2.3.5 made with the stripped GCC
and the glibc-2.3.5 made with the complete GCC were different in
their library sizes, for instance the 'libc-2.3.5.so' was 1329938
bytes when produced with the stripped GCC but 1293873 bytes when
produced with the complete GCC. The SuSE 10.0/ppc one was 1510896
bytes for their glibc-2.3.5-40 (the 32-bit library). Whether
gcc-3.4.4 produces smaller code than gcc-4.0.2 (used in SuSE) or
then there are other big changes in their own glibc-2.3.5...

  Comparing those sizes is almost everything one could do simply,
but tools like 'nm' and 'objdump' could allow one to investigate
the differences more deeply...

Re: Updating powerpc-crosscompile environment from gcc-2.95.3

[Frank Beesley]

Here is one configuration I got to build but I have not yet tested:

"../gcc-4.0.1/configure --prefix=$PREFIX --target=$TARGET 
--with-cpu=603e --disable-nls --disable-shared --disable-threads 
--enable-languages=c --without-headers --with-newlib"

"make all-gcc"

I am also trying the instructions I found for the Kuro Box at:
"http://geek.vtnet.ca/embedded/KuroBox/index.html"

The Kuro Box is an MPC8241 CPU which is a 603e core. I have not 
completed their instructions so can not speak personally to how well 
they work. Note that they are using gcc-3.4.3 so there could be some 
deviations needed.

Frank

Updating powerpc-crosscompile environment from gcc-2.95.3

[Kimmo Mustonen]

Hello!

I have a working powerpc-linux cross-compiling setup using binutils 2.16.1 
and gcc-2.95.3 on i386. Unfortunately I should upgrade it because

a) this gcc version works for building kernel 2.4 but not kernel 2.6
b) this gcc version works on i386 host but x86_64 host is not supported

I have tried to upgrade to gcc versions 3.0, 3.4.3, 3.4.4, 4.0.0 and 4.0.2 
but haven't been able to get any of them built but it fails quite early 
stage (the first step while still using newlib).

The log files contain the build scripts upto this stage:

1) A working version using gcc-2.95.3:

http://users.tkk.fi/u/kmustone/cross2953.log.txt

2) A non-working version using gcc-4.0.2 complaining about for 
instance pthread.h being missing. Configure, however, does not notice this 
problem or does not care about it (does not automatically use 
--disable-threads):

http://users.tkk.fi/u/kmustone/cross402.log.txt

3) A non-working version using gcc-4.0.2 --disable-threads. Looks quite 
promising until crti.o is missing.

http://users.tkk.fi/u/kmustone/cross402disablethreads.log.txt

"...powerpc-linux/bin/ld: crti.o: No such file: ..."

Where should this file come from? If not from gcc itself, the only other 
possible source at this point is binutils, but it is the same version that 
is working with gcc-2.95.3. If from gcc, why doesn't it get built or why 
isn't it found? There are some crti.asm or crti.s files under 
gcc-4.0.2/gcc/config/* but didn't see any obvious PowerPC-version 
there.

The build script used for gcc-4.0.2:

---8<---8<---
#!/bin/sh
set -e
mkdir -p /tmp/cross
mkdir -p /tmp/cross/src
cd /tmp/cross/src
bzip2 -dc /m/nfs/data/readwrite/sipo-external/binutils-2.16.1.tar.bz2 \
     | tar -xf -
cd binutils-2.16.1
./configure --target=powerpc-linux --prefix=/tmp/cross --nfp
make TARGET_CONFIGDIRS=
make install
PATH=/tmp/cross/bin:$PATH
export PATH
cd /tmp/cross/src
bzip2 -dc /m/nfs/data/readwrite/sipo-external/gcc-4.0.2.tar.bz2 \
     | tar -xf -
mkdir -p gcc-4.0.2-obj
cd gcc-4.0.2-obj
../gcc-4.0.2/configure --target=powerpc-linux --with-cpu=603e --nfp \
     --prefix=/tmp/cross --enable-shared --enable-languages="c" \
     --with-newlib --disable-threads
make TARGET_CONFIGDIRS=
---8<---8<---

Essentially the same steps work for gcc-2.95.3 but not any later version.

The host system is i386 Fedora Core 1 using linux kernel 2.4.31 but I have 
also other host environments that don't work any better.

Any suggestions?

Regards,
Kimmo Mustonen