lkml.org 
[lkml]   [2000]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRLIM_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]
\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.252 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site