Message-ID: <3972FAE9.D6AA04E1@softhome.net>
Date: Mon, 17 Jul 2000 14:24:09 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: law AT cygnus DOT com
CC: gcc AT gcc DOT gnu DOT org, DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Re: GCC headers and DJGPP port
References: <11363 DOT 963833127 AT upchuck>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Jeffrey A Law wrote:
> Well, I wouldn't expect it to be significantly different than how this
> is handled on other platforms.

There are differences between DJGPP and other platforms in how we 
avoid type redefinitions in our headers.

Suppose we put following in GCC headers

#ifdef __DJGPP__
#include <sys/djtypes.h>
#undef __DJ_size_t
#define __DJ_size_t
/* ... normal size_t definition as usual ... */

This way we get GCC size_t definition and DJGPP headers won't redefine it.
But everything will be OK only as long as GCC headers come first. Just do
#include <go32.h>
#include <stddef.h>
and we are in trouble - GCC header is unable to detect that size_t is 
already defined.

We could fix that by 

#ifdef __DJGPP__
#include <sys/djtypes.h>
__DJ_size_t
#undef __DJ_size_t
#define __DJ_size_t
#else
/* ... normal size_t definition as usual ... */
#endif

The difference is that GCC header will get and use size_t from DJGPP
instead of defining its own. Is it OK with you?

> If your header files are defining things in the wrong way in the wrong
> places, then fixincludes is your solution.

Fixincludes won't run on DJGPP in near future - we don't have pipe(), fork(),
etc. stuff. And shell script version has been removed.

Laurynas