Date: Tue, 18 Jul 2000 05:18:06 -0400 (EDT)
Message-Id: <200007180918.FAA06988@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: lauras AT softhome DOT net
CC: martin AT loewis DOT home DOT cs DOT tu-berlin DOT de, mrs AT windriver DOT com, gcc AT gcc DOT gnu DOT org,
        djgpp-workers AT delorie DOT com
In-reply-to: <39741C06.D246F354@softhome.net> (message from Laurynas Biveinis
	on Tue, 18 Jul 2000 10:57:42 +0200)
Subject: Re: GCC headers and DJGPP port
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: Tue, 18 Jul 2000 10:57:42 +0200
> From: Laurynas Biveinis <lauras AT softhome DOT net>
> 
> Eli Zaretskii wrote:
> > > GCC needs to know exactly what size_t and wchar_t is
> > 
> > This knowledge is accessible to GCC at build time, in the system
> > headers.
> 
> What about build system != target system?

I wasn't talking about that issue.  I don't understand why would this
be a problem in the cross build as well (GCC has both hosted and
target headers, and can take appropriate actions), but if it is, it's
possible to have different behavior in each case.  For example, GCC
could refrain from installing its own headers in the native case only.

> > > NULL is defined as __null on all platforms now
> > 
> > Not in DJGPP.  __null causes trouble in C programs.
> 
> I have trouble understanding why, if __null is a builtin.

Is __null a builtin in the C compiler?

Anyway, one reason that __null might cause trouble is that it breaks
previous versions of the library which were compiled with different
definition of NULL.  I think we've been discussing that on the DJGPP
developers list to death.

> (And why
> does it cause trouble on DJGPP, but not on other systems?)

I don't know enough about other systems to comment on that.

> Eli, is it a big difference for us, does GCC get definition from djgpp
> header, or from GCC target description one with Mark's patch?
> 
> + #undef SIZE_TYPE
> + #define SIZE_TYPE "long unsigned int"

Do I understand correctly that this should go into GCC distribution?
If so, I don't think I mind too much.  It does introduce a dependency
between the library and the compiler, which is unfortunate.  I think
we need to discuss this on the DJGPP devlopers' list.

> > And yes, we did read all the threads in GCC archives that appear to be
> > relevant, and we did discuss them at length.  But we still do not
> > understand the technical considerations that caused GCC to insist on
> > installing its own headers.  Please help us understand this.

> Uhm, how would you qualify following response:
> > Wrong. GCC needs to know exactly what size_t and wchar_t is, and it
> > must also provide the definition of NULL. size_t must be known so the
> > builtin functions can be declared properly. wchar_t must be known so
> > wide string literals can be emitted correctly. NULL is defined as
> > __null on all platforms now, so that overloading works correctly in
> > C++ (for C, it is something different).

I already posted a response: size_t and the rest *are* known at build
time: they are defined in the system headers.  GCC could simply use
them to build itself.