Date:	Thu, 27 Jul 2000 08:14:06 +0200 (CEST)
From:	Boszormenyi Zoltan <zboszor@externet.hu>
To:	linux-kernel@vger.rutgers.edu
Subject: RLIM_INFINITY inconsistency between archs

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--685023584-903639213-964678446=:32194
Content-Type: TEXT/PLAIN; charset=US-ASCII

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>


--685023584-903639213-964678446=:32194
Content-Type: APPLICATION/octet-stream; name="resource.h.diff.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.02.10007270814060.32194@prins.externet.hu>
Content-Description: 
Content-Disposition: attachment; filename="resource.h.diff.gz"

H4sICCU+fzkAA3Jlc291cmNlLmguZGlmZgDtl0tvm0AUhdfmVxwpi7YBbF7G
Disv2khuHS/yUFSpqjXG4zIKLzGQxIra394BnCjgGGLJSaO2IwuQgePr8825
A6qqwmdhdttjoetnC9ojPFCZObR7CeVRlri063Ujf9G5pAt8znwYNgzNER+9
Lw40TZJluV2icrvuGANHG5a3j0ZQ9aGim5DL3WgkQcLBgi5ZSHE6GZ/MpmIz
Pj/r6Jo4JR+wpTiJ2ezLp9Ppp8lsJskSeocScIiz7AycrLioKGAph0euKdII
c4os5OxHSBfd4sJLj7keAnJFOYi4IkQQJRSchpyChKsbsiou7NVKGU+Px9Px
+dfO+1/axeSDpErqZj2P6s8vnp2u68/HNwl3nc76UH3S/oDFvMl+3dE0pz9s
sr8m0Wy/0S/sL3fb7YeuiaJ7h5hmwZwmiJaly1j65DpKeLe0660A0m4Hy3Jc
TF4EE/FjjzTHpG86utbEqa5RA2XaD5zvc2KVObFePifAsVBWwNJ3/OFbBfMs
LSRuKBKaEhYi9SjEf8c18TOKZZTAjYKYpGzOfJauFFAeU5cR31/hhqUePl50
sYZMQ6yiDEkWgoWigFzL+G6bmJMkYTRRitOuuBcBfS7w+5H5u4OvoG/IqD28
amHfdyy9MaNViTr6gWMN/r0WmZuPp8c2FDwmidvSLy3HMJtY1DVaGqal2KJf
WsrwtVDQgoNIB6tFEVeUxnlqisJMXRlANk1RXl7Ys8IiinyKz5aAPIRDHOTj
riKrVH/lp7I1P3Hchkx3LLsJWVWhBZiR+yK2rb6s56zwZJcegc4dmoyAcGKr
FcXcs63WGdy84m+qtM7hYtG3XmUt2WtD+SMTliRB61p/37C3rPUVhf9PxDs8
ajGymY8TUeExnQMDaMJ6w7Ean7RqEi3h0Mtw6M+zH2/Bf+ARgM2K9vBO0tqj
hI9HbW8lu1CwSwr23/ReUsG0b0rcPNJaGJmO2ZiTmsReCL2lNoU9AfgNUqJ1
RjoRAAA=
--685023584-903639213-964678446=:32194--

-
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/