Date: Thu, 20 Jul 2000 19:29:03 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Mark E." <snowball3 AT bigfoot DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: GCC headers
In-Reply-To: <3976ECCE.11486.EB6CD@localhost>
Message-ID: <Pine.SUN.3.91.1000720192722.28548A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Thu, 20 Jul 2000, Mark E. wrote:

> _GCC_LIMITS_H is the include guard. _GCC_NEXT_LIMITS_H is defined and then 
> undefined in the generated "sysinclude.h" and ends up in gcc's include 
> directory:
> 
> /* syslimits.h stands for the system's own limits.h file.
>    If we can use it ok unmodified, then we install this text.
>    If fixincludes fixes it, then the fixed version is installed
>    instead of this text.  */
> 
> #define _GCC_NEXT_LIMITS_H		/* tell gcc's limits.h to recurse */
>  #include_next <limits.h>
> #undef _GCC_NEXT_LIMITS_H

So, if fixincludes worked in the DJGPP build, we would be using our 
limits.h, is that right?  Or am I missing something else?

> > Also, is this include_next gork present in the other headers GCC wants
> > to install?
> 
> Not that I'm aware of.

So the other headers need to be considered separately.

Thanks again for your help.