* Problem cross-compiling trunk for bfin
@ 2011-02-16 20:09 Henderson, Stuart
2011-02-16 23:02 ` Ian Lance Taylor
0 siblings, 1 reply; 3+ messages in thread
From: Henderson, Stuart @ 2011-02-16 20:09 UTC (permalink / raw)
To: gcc-help
Hi,
I'm relatively new to GCC, so please excuse my ignorance.
I've been trying to cross-compile GCC-trunk for Blackfin with uClibc, but it's currently failing and doesn't appear to have worked for quite some time. The most recent release tags are all fine, but I'm keen to get trunk building again.
The first problem I'm seeing is when building unwind-dw2.c (configure line and error message at the bottom). The problem seems to be caused by a change in the generation of tm.h in the following check in:
r160579 | rsandifo | 2010-06-10 21:23:43 +0100 (Thu, 10 Jun 2010) | 7 lines
gcc/
* configure.ac (tm_include_list): Add insn-constants.h.
* configure: Regenerate.
* Makefile.in (GTM_H): Move insn-constants.h here from...
(TM_H): ...here.
* mkconfig.sh: Remove special handling for insn-constants.h.
The change moves the inclusion of "insn-constants.h" from being conditional on:
#if defined IN_GCC && !defined GENERATOR_FILE && !defined USED_FOR_TARGET
to just:
#if defined IN_GCC
This causes insn-constants.h to be included here which defines various register macros that can then clash with the enum (of registers in the gregset_t array) in uClibc's sys/ucontext.h.
Although I've only hit this with bfin, it seems like it could easily hit other architectures. Not having a deep enough understanding of the gcc ecosystem nor why the change was made, I was hoping someone could explain the best way to resolve this?
Thanks for any help,
Stu
After installing target/uclibc headers for the sysroot, I configure gcc:
/home/shender/gnu/toolchain/gcc-4.6/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=bfin-uclinux --prefix=/home/shender/gnu/toolchain/bfin-uclinux --disable-libstdcxx-pch --with-sysroot=/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/runtime --enable-threads=posix --enable-languages=c --disable-threads --disable-libmudflap --disable-libgomp --disable-shared --enable-clocale=generic --disable-symvers --disable-libssp --disable-libffi --disable-libgcj --enable-version-specific-runtime-libs --enable-__cxa_atexit
and then make, which fails with:
/home/shender/gnu/toolchain/gcc_build-4.6/./gcc/xgcc -B/home/shender/gnu/toolchain/gcc_build-4.6/./gcc/ -B/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/bin/ -B/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/lib/ -isystem /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/include -isystem /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include -g -O2 -mcpu=bf532-none -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../../.././gcc -I/home/shender/gnu/toolchain/gcc-4.6/libgcc -I/home/shender/gnu/toolchain/gcc-4.6/libgcc/. -I/home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc -I/home/shender/gnu/toolchain/gcc-4.6/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc/unwind-dw2.c
In file included from /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include/ucontext.h:25:0,
from /home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include/signal.h:351,
from /home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc/config/bfin/linux-unwind.h:31,
from /home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc/unwind-dw2.c:333:
/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include/sys/ucontext.h:39:3: error: expected identifier before numeric constant
make[4]: *** [unwind-dw2.o] Error 1
make[4]: Leaving directory `/home/shender/gnu/toolchain/gcc_build-4.6/bfin-uclinux/bf532-none/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/home/shender/gnu/toolchain/gcc_build-4.6/bfin-uclinux/libgcc'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory `/home/shender/gnu/toolchain/gcc_build-4.6/bfin-uclinux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/shender/gnu/toolchain/gcc_build-4.6'
make: *** [all] Error 2
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problem cross-compiling trunk for bfin
2011-02-16 20:09 Problem cross-compiling trunk for bfin Henderson, Stuart
@ 2011-02-16 23:02 ` Ian Lance Taylor
2011-02-17 11:37 ` Henderson, Stuart
0 siblings, 1 reply; 3+ messages in thread
From: Ian Lance Taylor @ 2011-02-16 23:02 UTC (permalink / raw)
To: Henderson, Stuart; +Cc: gcc-help
"Henderson, Stuart" <Stuart.Henderson@analog.com> writes:
> r160579 | rsandifo | 2010-06-10 21:23:43 +0100 (Thu, 10 Jun 2010) | 7 lines
> gcc/
> * configure.ac (tm_include_list): Add insn-constants.h.
> * configure: Regenerate.
> * Makefile.in (GTM_H): Move insn-constants.h here from...
> (TM_H): ...here.
> * mkconfig.sh: Remove special handling for insn-constants.h.
>
> The change moves the inclusion of "insn-constants.h" from being conditional on:
> #if defined IN_GCC && !defined GENERATOR_FILE && !defined USED_FOR_TARGET
> to just:
> #if defined IN_GCC
>
> This causes insn-constants.h to be included here which defines various register macros that can then clash with the enum (of registers in the gregset_t array) in uClibc's sys/ucontext.h.
>
> Although I've only hit this with bfin, it seems like it could easily hit other architectures. Not having a deep enough understanding of the gcc ecosystem nor why the change was made, I was hoping someone could explain the best way to resolve this?
I doubt there is a clean way to solve this. Probably the simplest way
is to rename the conflicting constants in gcc/config/bfin/*.
Please open a bug report about this. See http://gcc.gnu.org/bugs/ .
Thanks.
Ian
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: Problem cross-compiling trunk for bfin
2011-02-16 23:02 ` Ian Lance Taylor
@ 2011-02-17 11:37 ` Henderson, Stuart
0 siblings, 0 replies; 3+ messages in thread
From: Henderson, Stuart @ 2011-02-17 11:37 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
Bug 47779 has been added to the database
Thanks Ian.
Stu
-----Original Message-----
From: Ian Lance Taylor [mailto:iant@google.com]
Sent: 16 February 2011 23:00
To: Henderson, Stuart
Cc: gcc-help@gcc.gnu.org
Subject: Re: Problem cross-compiling trunk for bfin
"Henderson, Stuart" <Stuart.Henderson@analog.com> writes:
> r160579 | rsandifo | 2010-06-10 21:23:43 +0100 (Thu, 10 Jun 2010) | 7 lines
> gcc/
> * configure.ac (tm_include_list): Add insn-constants.h.
> * configure: Regenerate.
> * Makefile.in (GTM_H): Move insn-constants.h here from...
> (TM_H): ...here.
> * mkconfig.sh: Remove special handling for insn-constants.h.
>
> The change moves the inclusion of "insn-constants.h" from being conditional on:
> #if defined IN_GCC && !defined GENERATOR_FILE && !defined USED_FOR_TARGET
> to just:
> #if defined IN_GCC
>
> This causes insn-constants.h to be included here which defines various register macros that can then clash with the enum (of registers in the gregset_t array) in uClibc's sys/ucontext.h.
>
> Although I've only hit this with bfin, it seems like it could easily hit other architectures. Not having a deep enough understanding of the gcc ecosystem nor why the change was made, I was hoping someone could explain the best way to resolve this?
I doubt there is a clean way to solve this. Probably the simplest way
is to rename the conflicting constants in gcc/config/bfin/*.
Please open a bug report about this. See http://gcc.gnu.org/bugs/ .
Thanks.
Ian
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-02-17 10:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-16 20:09 Problem cross-compiling trunk for bfin Henderson, Stuart
2011-02-16 23:02 ` Ian Lance Taylor
2011-02-17 11:37 ` Henderson, Stuart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).