Date:	Sun, 3 Dec 2000 08:59:32 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Laurynas Biveinis <lauras AT softhome DOT net>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Patch: make GCC & DJGPP headers compatible
In-Reply-To:	<3A293B7A.CD576D53@softhome.net>
Message-ID:	<Pine.SUN.3.91.1001203085529.1124J-100000@is>
MIME-Version:	1.0
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

On Sat, 2 Dec 2000, Laurynas Biveinis wrote:

> It was here all the time - but nobody told us to RTFM. At 
> very cores of GCC headers, those typedefs look like
> 
> typedef __SIZE_TYPE__ size_t;
> 
> Now __SIZE_TYPE__ is a predefined preprocessor macro, which contents are
> set for each port separately. And now djgpp.h in GCC sources has macros 
> defining size_t and few other types. So GCC headers have *our*
> definitions, after all.

What happens if we change the definition of wchar_t or wint_t?  Will that 
break GCC, or require to rebuild it after changing djgpp.h?

I thought that fixing fixincludes to DTRT with DJGPP should help solving 
these problems.  Doesn't it?

> > Could you please repeat, for this old man's sake, what do these
> > _SIZE_T symbols do?
> 
> Typedefs in GCC headers are surrounded by them. So this way we avoid
> errors, although both typedefs now define exactly the same thing.

What I'm trying to understand is whether our headers or the headers 
installed by GCC's "make install" procedure take precedence when you 
compile a program.

Also, what is the updated list of headers installed by GCC in the current 
CVS?

- Raw text -