Date: Tue, 18 Jul 2000 05:18:06 -0400 (EDT) Message-Id: <200007180918.FAA06988@indy.delorie.com> From: Eli Zaretskii 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 > > 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.