Conny Marco Menebröcker wrote:
On Monday 31 August 2009 16:56:00 Kai Ruottu wrote:
Conny Marco Menebröcker wrote:
I want to compile the gcc for xc16x controller.
I am using gcc 4.2 with two patches from the "gcc-patches" mailing list
archives.
A sanity check: Did you build and install the xc16x(-elf) targeted GNU
binutils before trying to configure and build GNU CC for xc16x(-elf)
target?
Yes.
What about patching the newlib(-1.14.0) sources for xc16x ? Maybe you
would like to have a (standard) C library for xc16x(-elf) too...
Ok, maybe that is it. I'll patch newlib and I'll see... thanks a lot
The (patched) newlib headers could be required when compiling libgcc
but usually the '--with-newlib' in GCC configure (required) makes the
headers not being required. For producing libiberty and libstdc++ they
would be needed...
I am running in the following error, but don't know how to fix it:
../../gcc/config/xc16x/lib1funcs.asm -o libgcc/./___divsi3.o
exec: 2: -o: not found
make[3]: *** [libgcc/./___divsi3.o] Error 1
> What does "exec: 2: -o: not found" mean?
Trying to exec the unexisting 'as' could cause something like this...
Just for a fun I tried building the gcc-4.2.0-20070316 prerelease
with the year-2006 xc16x patches without the preinstalled binutils
and got quite identical error from the '$build/gcc/as' seemingly
pointing to the native 'as'... Adding the binutils and removing
the faulty '$build/gcc/as' enabled the 'make' to succeed as far as
the libiberty build... There it crashed with :
/home/src/gnu/gcc-4.2.0-20070316/build/./gcc/xgcc
-B/home/src/gnu/gcc-4.2.0-20070316/build/./gcc/
-B/usr/local/xc16x-elf/bin/ -B/usr/local/xc16x-elf/lib/ -isystem
/usr/local/xc16x-elf/include -isystem /usr/local/xc16x-elf/sys-include
-c -DHAVE_CONFIG_H -O2 -Os -I. -I../../../libiberty/../include -W
-Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat
../../../libiberty/regex.c -o regex.o
In file included from ../../../libiberty/regex.c:638:
../../../libiberty/regex.c: In function â
../../../libiberty/regex.c:2638: varoitus: suuri kokonaisluku
implisiittisesti katkaistu etumerkittömäksi tyypiksi
../../../libiberty/regex.c:3173: varoitus: suuri kokonaisluku
implisiittisesti katkaistu etumerkittömäksi tyypiksi
../../../libiberty/regex.c:3185: varoitus: suuri kokonaisluku
implisiittisesti katkaistu etumerkittömäksi tyypiksi
/tmp/ccfQXKxG.s: Assembler messages:
/tmp/ccfQXKxG.s:5579: Error: internal error: fixup not contained within frag
/tmp/ccfQXKxG.s:8513: Error: internal error: fixup not contained within frag
make[2]: *** [regex.o] Virhe 1
Earlier there were errors about the 'include/setjmp.h' not having
definitions for the 'xc16x' CPU... But the three 'libgcc.a's
succeeded...
[root@Dell build]# find . -name libgcc.a
./gcc/xc16xs/libgcc.a
./gcc/libgcc.a
./gcc/xc16xl/libgcc.a
I removed the results, reconfigured and started 'make' again with the
binutils now in their expected places, $tooldir/bin and $tooldir/lib,
and the xc16x-patched newlib-1.14.0 headers in $tooldir/include and the
$tooldir/sys-include symlinked to it... The "from scratch" would show
how it is expected to succeed...
Maybe your $tooldir ($prefix/$target) for binutils is different from
the $tooldir for GCC ? Of course the '--prefix=' and '--target='
should receive the same values for both...
> Did the xgcc call the 'as'? I have 'as' and 'xc16x-as' but the 'as' is
> compiled for 'i486-linux-gnu'. Can that cause problems?
I naturally used the 'xc16x-elf' $target name... What the "bare" CPU
name would give for the binutils, is unclear. Usually one wants both
the CPU and the object format being seen, some older CPU targets could
also use the '-coff' and '-aout' object formats as alternatives. But
probably the bare name would mean the same as the '-elf' one, that
being the only possible $target type for the 'xc16x' CPU...
Let's see, the 'gcc/config.gcc' tells there being some difference:
xc16x*-*-elf)tmake_file="xc16x/t-xc16x"
tm_define="TARGET_DEFAULT=(MASK_TINY)"
use_fixproto=yes
;;
xc16x-*)
;;
And in binutils the:
[root@Dell binutils-2.19.51]# cd bfd
[root@Dell bfd]# grep xc16x config.bfd
xc16x-*-elf)
targ_defvec=bfd_elf32_xc16x_vec
[root@Dell bfd]# cd ../ld
[root@Dell ld]# grep xc16x configure.tgt
xc16x-*-elf) targ_emul=elf32xc16x
targ_extra_emuls="elf32xc16xl elf32xc16xs"
would claim that the "bare" 'xc16x' as the $target name wouldn't be
supported in usual binutils sources like the Linux ones :( How you
managed to produce binutils, gas and ld for the bare name is something
you should tell...
The 'xc16x-*-elf' target seemed to be supported already in the Linux
binutills-2.17.50.* sources. So no extra patches required for them.
