cpp found limits.h in FIXED_INCLUDE_DIR, but not in STANDARD_INCLUDE_DIR

Ian Lance Taylor iant@google.com
Tue Sep 16 11:29:00 GMT 2008


Zhang Le <r0bertz@gentoo.org> writes:

> I have just tried gcc 4.4.0_alpha20080912.
> But I encountered some problems related to <limits.h>.
> like SSIZE_MAX/PATH_MAX undefined.
> It turned out that the root cause seems to be gcc used the wrong limits.h, i.e.
> /usr/lib/gcc/mipsel-unknown-linux-gnu/4.4.0-alpha20080912/include-fixed/limits.h
> (please see the details at the bottom of this email)
>
> this file only contains some of the system's max value and it can't replace
> /usr/include/limits.h. Presumably (is it?) cpp will stop searching for limits.h
> when it finds the first one in cpp_include_defaults array. And FIXED_INCLUDE_DIR
> is before STANDARD_INCLUDE_DIR.
>
> So i am a little confused. How come this works in previous versions? 
> BTW, the gcc i used was cross compiled on a x86 host.
>
> Would you please explain a little bit about how fixed headers are supposed to
> work? Is this a bug or a new feature but i missed something here?

If you are building a cross-compiler, it does not make sense to use
/usr/include/limits.h.  gcc is providing a minimal limits.h which
supports everything required by ISO C99.  SSIZE_MAX and PATH_MAX are
defined by POSIX, and are inherently dependent on your operating
system.  They would normally be provided by the version of limits.h
from your C library.

If you have a C library for your target system which provides
limits.h, then you need to use the --with-sysroot option when
configuring gcc to tell it where to find the target C library.

If you don't have a C library for your target system, then that's the
problem you need to solve first.  gcc does not provide a C library.

Ian



More information about the Gcc mailing list