On Tue, 22 Feb 2005, David Daney wrote:
> > I'm trying to build the current glibc with my RaQ2, everything builds ok,
> > until I start compiling strace.
> > syscall.c: In function `dumpio':
> > syscall.c:449: error: `SYS_read' undeclared (first use in this function)
> > syscall.c:449: error: (Each undeclared identifier is reported only once
> > syscall.c:449: error: for each function it appears in.)
> > syscall.c:465: error: `SYS_write' undeclared (first use in this function)
> > syscall.c: In function `syscall_fixup':
> > syscall.c:1265: warning: unused variable `pid'
> > syscall.c: In function `trace_syscall':
> > syscall.c:2481: error: `SYS_exit' undeclared (first use in this function)
> > make: *** [syscall.o] Error 1
> > make: Leaving directory `/usr/src/strace-4.5.9'
> > make: *** [all] Error 2
> > Which leads me to check syscall.h, then I noticed a big difference from
> > my x86 version to this version, all the SYS_ entries are missing. Did I
> > build it wrong or is this a glibc issue, due to the addition of the
> > mips32 and mips64 directories.
> > Here is my bug report with the glibc folks for everyone's reference.
> > http://sources.redhat.com/bugzilla/show_bug.cgi?id=758
> It seems that you might need some (but not all) of the patch I posted here:
> Specifically I think you will need at least the parts that add
> #include <sgidefs.h>
> To many of the .h files. Basically any file that uses the symbol _MIPS_SIM
> and friends needs to either directly or indirectly include sgidefs.h
> You may also need:
> And something like this:
The culprit is elsewhere. The glibc's syscall number translator script
doesn't work with asm-mips/unistd.h as of Linux 2.6 (you could have
probably used 2.4 headers instead; I'm not sure if that is compatible with
"--enable-kernel=2.6.0", though). A correct fix has been prepared and
proposed by Richard Sandiford and is available here:
"http://sourceware.org/ml/libc-alpha/2004-11/msg00097.html". I would
expect this patch to have been applied before 2.3.4, but apparently this
hasn't happened. That's regrettable and I fear it's the result of glibc
being somewhat inadequately maintained for MIPS/Linux these days, sigh...
I'm not sure what the maintenance plan is for the 2.3 branch of glibc,
but if 2.3.5 is ever going to happen, the Richard's patch is one of the