This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: #include <limits.h>, interdepency between gcc and glibc headers?
- To: gcc-bugs at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com
- Subject: Re: #include <limits.h>, interdepency between gcc and glibc headers?
- From: Ben Collins <bcollins at debian dot org>
- Date: Fri, 27 Oct 2000 13:06:47 -0400
- References: <20001027120751.E10561@visi.net>
On Fri, Oct 27, 2000 at 12:07:51PM -0400, Ben Collins wrote:
> 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).
Oof, this seems to be fixed in glibc 2.1.96 (just got done compiling it).
BTW, it builds and installs fine with gcc 2.95.2 on sparc-linux :)
Ben
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'