Re: [GNU] [SuperH] [M32R] limits.h issue

[Ralf Corsepius <ralf_corsepius at rtems dot org>]

On Thu, 2004-11-25 at 11:53 +0900, NIIBE Yutaka wrote:
> Here're two patches for GNU system (specifically GNU/Linux) on SuperH
> and M32R.  I think that this is common problem among GNU system in
> general, but I report specific fixes for SuperH and M32R this time.
> 
> Background:
> We're now cross-building Debian GNU/Linux for M32R (I was doing that
> for SuperH around 2000).  I encountered this problem around Y2K, but
> at that time, I didn't able to track down what the problem is.
> 
> There is an issue that limits.h is wrongly generated when building
> cross compiler.  Specifically, LIMITS_H_TEST in gcc/Makefile should be
> evaluated to be `true', and limits.h should be generated so that it is:
> 	  limitx.h + glimits.h + limity.h
> That's needed because we have glibc's limits.h.
> 
> However, LIMITS_H_TEST will be evaluated to be `false', because it
> checks the existence of $(gcc_tooldir)/sys-include.
For RTEMS, we are facing the same issue and are working around it by
overriding LIMITS_H_TEST = true in config/t-rtems.

cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18643

> The problem is (I think):
> 	When building cross GCC, it assumes that the header files are
> 	placed at $(gcc_tooldir)/sys-include.  It is true for non-GNU
> 	system, but for GNU system where we use GNU C library as
> 	native library, it's $(gcc_tooldir)/include instead.
Not quite. There exist other systems but GlibC-based systems, to whom
the same assumption applies, e.g. newlib based systems.

Ralf