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.
Peter
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.
H.J.
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?
H.J.
----
2002-03-25 H.J. Lu <[email protected]>
* sysdeps/unix/sysv/linux/arm/kernel-features.h: New. Define
__NR_ugetrlimit if not defined.
* sysdeps/unix/sysv/linux/cris/kernel-features.h: Likewise.
* sysdeps/unix/sysv/linux/i386/kernel-features.h: Likewise.
* sysdeps/unix/sysv/linux/m68k/kernel-features.h: Likewise.
* sysdeps/unix/sysv/linux/powerpc/kernel-features.h: Likewise.
* sysdeps/unix/sysv/linux/s390/s390-32/kernel-features.h: Likewise.
* sysdeps/unix/sysv/linux/sh/kernel-features.h: Likewise.
--- sysdeps/unix/sysv/linux/arm/kernel-features.h.rlimit Mon Mar 25 11:32:07 2002
+++ sysdeps/unix/sysv/linux/arm/kernel-features.h Mon Mar 25 11:32:28 2002
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/i386/kernel-features.h>
--- sysdeps/unix/sysv/linux/cris/kernel-features.h.rlimit Mon Mar 25 11:32:07 2002
+++ sysdeps/unix/sysv/linux/cris/kernel-features.h Mon Mar 25 11:32:28 2002
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/i386/kernel-features.h>
--- sysdeps/unix/sysv/linux/i386/kernel-features.h.rlimit Mon Mar 25 11:31:54 2002
+++ sysdeps/unix/sysv/linux/i386/kernel-features.h Mon Mar 25 11:35:31 2002
@@ -0,0 +1,8 @@
+#include <sysdeps/unix/sysv/linux/kernel-features.h>
+
+/* We have to make sure __NR_ugetrlimit is defined, other wise
+ [sg]etrlimit in the glibc compiled under kernel 2.2 won't work
+ under kernel 2.4 and above. */
+#ifndef __NR_ugetrlimit
+# define __NR_ugetrlimit 191
+#endif
--- sysdeps/unix/sysv/linux/m68k/kernel-features.h.rlimit Mon Mar 25 11:32:44 2002
+++ sysdeps/unix/sysv/linux/m68k/kernel-features.h Mon Mar 25 11:32:40 2002
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/i386/kernel-features.h>
--- sysdeps/unix/sysv/linux/powerpc/kernel-features.h.rlimit Mon Mar 25 11:33:39 2002
+++ sysdeps/unix/sysv/linux/powerpc/kernel-features.h Mon Mar 25 11:35:39 2002
@@ -0,0 +1,8 @@
+#include <sysdeps/unix/sysv/linux/kernel-features.h>
+
+/* We have to make sure __NR_ugetrlimit is defined, other wise
+ [sg]etrlimit in the glibc compiled under kernel 2.2 won't work
+ under kernel 2.4 and above. */
+#ifndef __NR_ugetrlimit
+# define __NR_ugetrlimit 190
+#endif
--- sysdeps/unix/sysv/linux/s390/s390-32/kernel-features.h.rlimit Mon Mar 25 11:33:09 2002
+++ sysdeps/unix/sysv/linux/s390/s390-32/kernel-features.h Mon Mar 25 11:32:58 2002
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/i386/kernel-features.h>
--- sysdeps/unix/sysv/linux/sh/kernel-features.h.rlimit Mon Mar 25 11:33:22 2002
+++ sysdeps/unix/sysv/linux/sh/kernel-features.h Mon Mar 25 11:33:17 2002
@@ -0,0 +1 @@
+#include <sysdeps/unix/sysv/linux/i386/kernel-features.h>
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
On Mon, Mar 25, 2002 at 03:01:30PM -0500, Daniel Jacobowitz wrote:
> 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.
To take the advantage of 2.4, it should be yes. But to run correctly
under 2.4, the answer should no. On the other hand, I agree it is more
a kernel problem than a glibc problem since the older glibc binaries
won't work correctly under 2.4.
H.J.