Re: [Buildroot] Buildroot Compile Errors for SH4
On Tue, Apr 10, 2007 at 11:43:07PM +0200, Carmelo Amoroso wrote: Paul Mundt wrote: This is the syscall() definition in the __USE_MISC case, and it's certainly not limited to SH. There are hardly any users that implement syscall() using varargs, so this will break other places as well. Hi Paul, it's very strange, but I'm able to build the snapshot of trunk for sh4 without problems (with my last patch to fix procfs.h committed by Mike). I'm using cross gcc4.1.1/binutils 2.17.50.0.5 on both MacOSX 10.4 (darvin 8.9.1) and RH Linux. I've checked that __USE_MISC is defined for me. My guess would be that this is something that was introduced with gcc 4.2, I've not hit this with 4.1.1 in the past either.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [Buildroot] Buildroot Compile Errors for SH4
Perhaps somebody on the uClibc list is better suited to help.
On Tue, Apr 10, 2007 at 03:43:32PM -0400, Bill Traynor wrote:
On 4/10/07, Bill Traynor [EMAIL PROTECTED] wrote:
Hi All,
Trying to compile Buildroot for SH4 (from April 10th snapshot
http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2)
with the following config:
2.6.20 Kernel Headers
uClibc - daily snapshot
binutils 2.17.50.0.14
GCC 4.2
Received the following error:
CC libc/sysdeps/linux/sh/syscall.os
libc/sysdeps/linux/sh/syscall.c:11: error: conflicting types for 'syscall'
./include/unistd.h:1016: error: previous declaration of 'syscall' was here
So the offending code is:
syscall.c
long syscall(long sysnum,
long arg1, long arg2, long arg3,
long arg4, long arg5, long arg6)
{
register long __sc3 __asm__ (r3) = sysnum;
register long __sc4 __asm__ (r4) = (long) arg1;
register long __sc5 __asm__ (r5) = (long) arg2;
register long __sc6 __asm__ (r6) = (long) arg3;
register long __sc7 __asm__ (r7) = (long) arg4;
register long __sc0 __asm__ (r0) = (long) arg5;
register long __sc1 __asm__ (r1) = (long) arg6;
__asm__ __volatile__ (
trapa %1
: =z (__sc0) \
: i (__SH_SYSCALL_TRAP_BASE + 6),
0 (__sc0), r (__sc4), r (__sc5), r (__sc6), r (__sc7), \
r (__sc3), r (__sc1) \
: memory );
__syscall_return(long,__sc0);
}
and unistd.h:
extern long int syscall (long int __sysno, ...) __THROW;
The question now is how to fix this for SH.
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: [Buildroot] Buildroot Compile Errors for SH4
On Tue, Apr 10, 2007 at 09:58:02PM +0200, Bernhard Fischer wrote:
On Tue, Apr 10, 2007 at 03:43:32PM -0400, Bill Traynor wrote:
On 4/10/07, Bill Traynor [EMAIL PROTECTED] wrote:
CC libc/sysdeps/linux/sh/syscall.os
libc/sysdeps/linux/sh/syscall.c:11: error: conflicting types for 'syscall'
./include/unistd.h:1016: error: previous declaration of 'syscall' was here
So the offending code is:
syscall.c
long syscall(long sysnum,
long arg1, long arg2, long arg3,
long arg4, long arg5, long arg6)
{
register long __sc3 __asm__ (r3) = sysnum;
register long __sc4 __asm__ (r4) = (long) arg1;
register long __sc5 __asm__ (r5) = (long) arg2;
register long __sc6 __asm__ (r6) = (long) arg3;
register long __sc7 __asm__ (r7) = (long) arg4;
register long __sc0 __asm__ (r0) = (long) arg5;
register long __sc1 __asm__ (r1) = (long) arg6;
__asm__ __volatile__ (
trapa %1
: =z (__sc0) \
: i (__SH_SYSCALL_TRAP_BASE + 6),
0 (__sc0), r (__sc4), r (__sc5), r (__sc6), r (__sc7), \
r (__sc3), r (__sc1) \
: memory );
__syscall_return(long,__sc0);
}
and unistd.h:
extern long int syscall (long int __sysno, ...) __THROW;
The question now is how to fix this for SH.
This is the syscall() definition in the __USE_MISC case, and it's
certainly not limited to SH. There are hardly any users that implement
syscall() using varargs, so this will break other places as well.
We could convert syscall() to use varargs, though we'd have to take the
length of the arglist to add to __SH_SYSCALL_TRAP_BASE, though as
_syscall6() is the worst case, so perhaps that's fine in the general
case.
I suppose the question is why some are using varargs and others aren't. I
don't mind changing it if there's a consensus. In any event, this will
hit pretty much all of the other architectures, too..
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
