#include <limits.h>, interdepency between gcc and glibc headers?

[Ben Collins <bcollins at debian dot org>]

Trying to debug a problem with LONG_BITS always being defined to 64, I
found out that gcc's limits.h depends on glibc's version (to check for
__LIMITS_H and also the OSF/1 LIMITS_H), but then glibc's limits.h also
depends on gcc's version to define LONG_MAX (by checking if _GNUC_ is
defined and >= 2).

Now, gcc's limits.h gets loaded first, then includes syslimits.h, which
calls include_next and pulls in glibc's limits.h. This is done before
anything is defined in gcc's version (so it can check for the above).

So what's the solution? I'm not sure if this is gcc's fault (CVS as of a
week ago, also a problem with gcc 2.95.2)

As such, LONG_BITS is always defined as "64" (since LONG_MAX is not
defined).

Ideas?

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'