This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
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
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'
/home2/usr/local/sh-elf/bin > ./as --help Usage: ./as [option...] [asmfile...] Options: -a[sub-option...] turn on listings
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 :
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...
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |