From: "Mark E." <snowball3 AT bigfoot DOT com>
To: Eli Zaretskii <eliz AT delorie DOT com>, djgpp-workers AT delorie DOT com
Date: Sun, 14 May 2000 00:38:12 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: more gcc issues
Message-ID: <391DF574.6037.367C59@localhost>
In-reply-to: <200005132124.RAA16266@indy.delorie.com>
References: <391D4709 DOT 24006 DOT 260204 AT localhost> (snowball3 AT bigfoot DOT com)
X-mailer: Pegasus Mail for Win32 (v3.12c)
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

> I don't like that attitude, but the question is: what does that mean
> in practical terms?  Do GCC-supplied headers contradict ours to the
> degree that it's impractical to make them compatible?  If so, we
> should fight that attitude.
> 

The FreeBSD poster int that thread tried fighting it, and got nowhere. The 
GCC headers that cause problems for DJGPP are stddef.h and stdargs.h and 
probably varargs.h. When you compile a program that uses 'size_t', 'wchar_t', 
or 'va_list', you get redefinition errors.

You don't notice this with the DJGPP ports because Andris leaves those three 
files out of the DJGPP ports of GCC. Since our goal is for gcc 3.0 to work 
without changes, we need to find a different solution. 

The main problem is that GCC's headers and our headers don't know when the 
other has defined a type like 'size_t'. For example, GCC's stddef.h doesn't 
understand __DJ_size_t and DJGPP's headers don't understand the macros that 
GCC's stddef.h defines to signal that it defined 'size_t'.