newbie questions remain regarding crosstool with an arm920t target (arm_920TDI)
Kai Ruottu
karuottu@mbnet.fi
Wed Oct 22 09:22:00 GMT 2003
Robert Schwebel <robert@schwebel.de> wrote:
> On Fri, Oct 17, 2003 at 06:01:30PM +0200, Marc Kleine-Budde wrote:
> > Hmmm - I dunno if Robert Schwebel's listening,
>
> He is :)
>
> > but he prefers a gcc-2.95.3 binutils-2.13.2.1 glibc-2.2.5 toolchain
> > for his arm projects without special -mcpu or -with-cpu switches....
>
> Well, this was until now. I recently asked on the arm-linux-kernel list
> again and the gurus there seem to be happy with the latest gcc-3.3
> versions now, so it might be time to give it a try.
But what about using glibc-2.3.2 instead of glibc-2.2.5 ? When I built
glibc-2.2.5 with gcc-2.95.3 in 2002, there weren't any big problems,
but now when using gcc-3.3.1 to compile glibc-2.3.2 the following problem
appeared:
In file included from ../linuxthreads/sysdeps/pthread/sigaction.c:53,
from ../linuxthreads/sysdeps/pthread/sigaction.c:53,
from ../linuxthreads/sysdeps/pthread/sigaction.c:29:
../sysdeps/unix/sysv/linux/arm/sigaction.c: In function `__libc_sigaction':
../sysdeps/unix/sysv/linux/arm/sigaction.c:100:
error: asm-specifier for variable `_a1' conflicts with asm clobber list
../sysdeps/unix/sysv/linux/arm/sigaction.c:139:
error: asm-specifier for variable `_a1' conflicts with asm clobber list
make[2]: *** [/home1/src/glibc-2.3.2/build/signal/sigaction.o] Error 1
make[2]: Leaving directory `/home1/src/glibc-2.3.2/signal'
Both errors came from resolving the same macro, like :
result = INLINE_SYSCALL (rt_sigaction, 4, sig,
act ? __ptrvalue (&kact) : NULL,
oact ? __ptrvalue (&koact) : NULL, _NSIG / 8);
The kernel headers where this (probably) was defined were first from the linux-2.4.19
sources but updating them to the latest (I have) 2.4.22 didn't help at all...
So the up-to-date gcc-3.3.1, glibc-2.3.2 and linux-2.4.22 sources don't seem
to work together at all what becomes to 'arm-linux-gnu'... What about the other
Linux-targets?
My PC is just trying to build glibc-2.3.2 for 'sh-linux-gnu' (with the SH3 defaults).
The build stopped with 'stdio-common/sscanf.c', this function being a builtin with
gcc-3.3.1 for SH, but a hack via wrapping the function with '#ifndef __sh__' and
'#endif' seemed to allow the build to continue... What would be the 'right' way to
fix this? Trying gcc-3.2.3 first told that it didn't care about the 'va_start()' issue
here, so what would be the right 'plain vanilla' FSF-GCC for building glibc-2.3.2
for 'sh-linux-gnu' just 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
More information about the crossgcc
mailing list