Messages in this thread | | | Date | Thu, 27 Jul 2000 08:14:06 +0200 (CEST) | From | Boszormenyi Zoltan <> | Subject | RLIM_INFINITY inconsistency between archs |
| |
Hi!
I have problems compiling egcs snaphots with 2.4.0-test kernel sources on a glibc-2.1.2 system. (RH 6.1) The problem can be reduced to this:
*****test.c************** #include <sys/resource.h> int main(void) { return 0; } *****test.c************** [root@localhost /root]# gcc -Wall -o test test.c In file included from /usr/include/sys/resource.h:25, from test.c:1: /usr/include/bits/resource.h:109: warning: 'RLIM_INFINITY' redefined /usr/include/asm/resource.h:25: warning: this is the location of the previous definition *************************
/usr/include/asm is a symlink to /usr/src/linux/include/asm, as in the original distribution but /usr/src/linux is a 2.4.0-testX tree. With a 2.2.X source tree, it does not produce any warning.
Because of the warning above, egcs' configure script produces the following: *****auto-host.h********* ... /* Define if you have the getrusage function. */ #define HAVE_GETRUSAGE 1 ... /* Define if you have the <sys/resource.h> header file. */ /* #undef HAVE_SYS_RESOURCE_H */ ... *****auto-host.h*********
Because of this gcc.c will not #include <sys/resource.h>, but it wants to use e.g. struct rusage and getrusage().
Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard "don't use kernel headers directly" answer. But neither gcc.c, neither the above small program use kernel headers. I suppose he referred to /usr/include/linux/* as (I think) he did not understand me.
I looked at the kernel sources and found that two architectures (ppc and sh) protects RLIM_INFINITY with #ifdef __KERNEL__ ... #endif so it does not conflicts with glibc. The attached patch does the same on all other architectures.
The other solution would be to fix glibc so it does not redefine RLIM_INFINITY but that is the glibc developers' business.
Regards, Zoltan Boszormenyi <zboszor@mail.externet.hu>
[unhandled content-type:application/octet-stream] | |