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>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:23 EST