This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Support __NR_ugetrlimit for 2.2 kernel (Re: Does e2fsprogs-1.26 work on mips?)


On Mon, Mar 25, 2002 at 11:45:11AM -0800, H . J . Lu wrote:
> On Mon, Mar 25, 2002 at 11:11:17AM -0800, H . J . Lu wrote:
> > On Mon, Mar 25, 2002 at 11:00:05AM -0800, Peter Hartley wrote:
> > > H J Lu wrote:
> > > > What are you talking about? It doesn't matter which kernel header
> > > > is used. glibc doesn't even use /usr/include/asm/resource.h nor
> > > > should any user space applications.
> > > 
> > > It's not about /usr/include/asm/resource.h, it's about
> > > /usr/include/asm/unistd.h, where the syscall numbers are defined.
> > > 
> > > This is presumably what the "#ifdef __NR_ugetrlimit" in
> > > sysdeps/unix/sysv/linux/i386/getrlimit.c is meant to be testing against --
> > > nothing in the glibc-2.2.5 distribution itself defines that symbol. Surely a
> > > Linux glibc doesn't compile without the target system's linux/* and asm/*
> > > headers?
> > > 
> > > 2.4's /usr/include/asm/unistd.h defines __NR_ugetrlimit but 2.2's doesn't.
> > > 
> > 
> > I see. I think glibc should either require 2.4 header files under
> > <asm/*.h> and <linux/*.h>, or define __NR_ugetrlimit if it is not
> > defined.
> > 
> > 
> 
> How about this patch?


Just require 2.4 kernel headers if you want to work under a 2.4 kernel. 
It may not have been documented/enforced, but I believe this was
already true.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]