more problems building gcc3.3.3 for the sh-elf target

[Kai Ruottu]

Alexander Gdalevich wrote:

> However, I am running into a strange problem building libgcc:
> 
> I have configured bootstrap gcc as follows:

  "Bootstrap GCC" is the GCC you are using to produce the executables
for your new GCC. The recent "Installing GCC" manual (gcc-3.4) :

--------------------------- clip ---------------------------------------
2 Prerequisites

GCC requires that various tools and packages be available for use in the
build procedure. Modifying GCC sources requires additional tools described
below.

Tools/packages necessary for building GCC

ISO C90 compiler
   Necessary to bootstrap the GCC package, although versions of GCC prior
   to 3.4 also allow bootstrapping with a traditional (K&R) C compiler.
   To make all languages in a cross-compiler or other configuration where
   3-stage bootstrap is not performed, you need to start with an existing
   GCC binary (version 2.95 or later) because source code for language
   frontends other than C might use GCC extensions.
--------------------------- clip ---------------------------------------

should make this term clear. You seem to have produced something I would
call a "stripped GCC", a GCC without any extra target libraries produced
in the build "stage1".  Why you did this?

> ../gcc-3.3.3/configure --target=sh-elf --prefix=/gcc_build/sh4 \
> --enable-languages=c --disable-multilib --with-newlib \
> --without-headers --program-prefix=sh-elf- \
> --disable-threads --disable-nls --disable-shared \
> -v 2>&1 | tee configure.out

  Most of these options to configure are pure bullshit, you should get your
GCC with C/C++ already in the stage1 when configuring with:

  ../gcc-3.3.3/configure --target=sh-elf --prefix=/gcc_build/sh4 \
  --with-newlib --program-prefix=sh-elf- --enable-languages=c,c++

and having the generic newlib headers copied into your chosen
'$prefix/$target/include', ie. into the

   /gcc_build/sh4/sh-elf/include

in this case. You also should copy or symlink the headers:

   limits.h, stdio.h, stdlib.h, string.h, time.h, unistd.h

into the '$prefix/$target/sys-include', here:

   /gcc_build/sh4/sh-elf/sys-include

This is because of the well-known 'sys-include bug' -- these
target headers must be seen in the 'sys-include', otherwise
they will be substituted with unworking stubs during the GCC
build!  Just browse the messages on the archive of this list
and you will see how much hassle this bug has caused...

  The '--with-newlib' enables the GCC build to succeed when
only the generic newlib headers are available during the GCC
build. The gcc-3.0 and maybe still gcc-3.1 had bugs in this
issue, but gcc-3.2 and gcc-3.3 will work again. Just like the
gcc-2.95 and the GCCs before it.

> The error I get is:
> /crossgcc/build_gcc/gcc/xgcc -B/crossgcc/build_gcc/gcc/ 
> -B/gcc_build/sh4/sh-elf/
> bin/ -B/gcc_build/sh4/sh-elf/lib/ -isystem /gcc_build/sh4/sh-elf/include 
> -O2  -D
> IN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
> -Wmissing-
> prototypes -isystem ./include   -g  -DIN_LIBGCC2 
> -D__GCC_FLOAT_NOT_NEEDED -Dinhi
> bit_libc -I. -I. -I../../gcc-3.3.3/gcc -I../../gcc-3.3.3/gcc/. 
> -I../../gcc-3.3.3
> /gcc/config -I../../gcc-3.3.3/gcc/../include -DL_ashiftrt 
> -xassembler-with-cpp -
> c ../../gcc-3.3.3/gcc/config/sh/lib1funcs.asm -o libgcc/./_ashiftrt.o
> as: unrecognized option `-big'

  This option is supported in the latest binutils releases:

/home2/usr/local/sh-elf/bin > ./as --help
Usage: ./as [option...] [asmfile...]
Options:
   -a[sub-option...]       turn on listings

<snip>

SH options:
-little                 generate little endian code
-big                    generate big endian code
-relax                  alter jump instructions for long displacements
-small                  align sections to 4 byte boundaries, not 16
-dsp                    enable sh-dsp insns, and disable floating-point ISAs.
-isa=[sh4
     | sh4a
     | dsp               same as '-dsp'
     | fp
     | any]

  So you should update your binutils to something more up-to-date version
like:

/home2/usr/local/sh-elf/bin > ./as --version
GNU assembler 2.14.90.0.8 20040114
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `sh-elf'.

> It is using the correct assembler, and binutils were built
> 
> using  ../binutils-2.14/configure  --target=sh-elf 
> --prefix=/build_gcc/sh4 -v
> 
> Do I have bad karma or something???

  No, you are maybe using some obsolete stuff for SH/ELF... Things will
change quite fast in the open sources so snapshots and Linux distros
etc. will sometimes be required. In this case the Linux/SH seems to
have required some changes to the ELF format...

  Or, if the previous wasn't just a typo, you did make one of these
newbie/artistic (showing creativity) errors, because your GCC configure
had it otherwise :

 > ../gcc-3.3.3/configure --target=sh-elf --prefix=/gcc_build/sh4 \

  As you can see: "build_gcc" != "gcc_build" !  You should use the
same $prefix for both binutils and GCC !

  So the native 'as' could have been used instead because the 'sh-elf'
targeted 'as' wasn't found at '$prefix/$target/bin'...

> ----------------------------------------------------------------
> "Normal people ... believe that if it ain't broke, don't fix it. 
> Engineers believe that if it ain't broke, it doesn't have enough 
> features yet."

  Should I interpret this as that you made your GCC build as complicated
and time-consuming as possible?  In order to get more time for some
coffee-breaks. Building takes time and building GCC twice gives two
coffee-breaks instead of only one... I would assume the cross-GCC FAQs
telling how one builds those newlib-based GCCs, so whatever wacky build
instructions with 'stripped-GCC's being required will be given somewhere
else, just don't believe them but use your own brains and think why that
'--with-newlib' option is there now...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com