Date: Fri, 21 Jul 2000 14:12:28 -0400 (EDT)
Message-Id: <200007211812.OAA11217@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: martin AT loewis DOT home DOT cs DOT tu-berlin DOT de
CC: mrs AT windriver DOT com, djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org
In-reply-to: <200007211526.RAA01901@loewis.home.cs.tu-berlin.de>
	(martin AT loewis DOT home DOT cs DOT tu-berlin DOT de)
Subject: Re: GCC headers and DJGPP port
References: <200007192144 DOT OAA01294 AT kankakee DOT wrs DOT com> <200007200644 DOT CAA09337 AT indy DOT delorie DOT com> <200007201115 DOT NAA14806 AT loewis DOT home DOT cs DOT tu-berlin DOT de> <200007210748 DOT DAA10668 AT indy DOT delorie DOT com> <200007211526 DOT RAA01901 AT loewis DOT home DOT cs DOT tu-berlin DOT de>
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

> Date: Fri, 21 Jul 2000 17:26:47 +0200
> From: "Martin v. Loewis" <martin AT loewis DOT home DOT cs DOT tu-berlin DOT de>
> 
> I can understand that there is additional contents in your limits.h. I
> fail to see what this has to do with GCC installing its own copy of
> limits.h into a gcc directory. It is common in GCC installations to
> have multiple copies of limits.h, and chain them together with
> #include_next. This works very well on other GCC ports (e.g. Linux,
> Solaris) - why doesn't it work on DJGPP?

#include_next does work, but it requires various #ifdef's to protect
it from multiple redefinitions, and these #ifdef's introduce special
reserved symbols that make maintenance harder.  Where this is
necessary, it is done, but we would like to make the number of such
headers as small as possible.

I think if we discuss each of the headers that GCC currently installs,
we could come to a reasonable compromise as to what can go and what
needs to stay.

> Forcing GCC not to install certain headers does not minimize
> problems.

It does minimize the potential for a new GCC version to break existing
code due to incompatible definitions in the headers distributed with
GCC.

> Instead, if a new feature in GCC requires support in header
> files, your port would break as your libraries would not provide that
> support.

This is a different problem, one which we are more willing to risk
having.  If a new feature cannot be used until the library is
upgraded, that's semi-okay, since that new feature didn't exist
previously.  But if a new release of the compiler breaks code which
worked before that, that is a much more serious problem.