delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/07/18/14:44:35

Date: Tue, 18 Jul 2000 20:35:44 +0200
Message-Id: <200007181835.UAA00972@loewis.home.cs.tu-berlin.de>
From: "Martin v. Loewis" <martin AT loewis DOT home DOT cs DOT tu-berlin DOT de>
To: eliz AT is DOT elta DOT co DOT il
CC: mrs AT windriver DOT com, gcc AT gcc DOT gnu DOT org, djgpp-workers AT delorie DOT com
In-reply-to: <200007180810.EAA06916@indy.delorie.com> (message from Eli
Zaretskii on Tue, 18 Jul 2000 04:10:45 -0400 (EDT))
Subject: Re: GCC headers and DJGPP port
References: <200007171736 DOT KAA29313 AT kankakee DOT wrs DOT com> <200007171834 DOT OAA06211 AT indy DOT delorie DOT com> <200007172102 DOT XAA07817 AT loewis DOT home DOT cs DOT tu-berlin DOT de> <200007180810 DOT EAA06916 AT indy DOT delorie DOT com>
User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko")
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

> > 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.

No. That won't work in a cross-compiler, and it is not possible to
exactly reconstruct a typedef. For example, on some targets, the size
of a type might vary depending on some target options. On those
systems, the gcc-provided header files would change
accordingly. Clearly, when gcc is *compiled*, only one of these
settings is accessible.

Besides, this is not where gcc currently draws this information from,
so it is not accessible in the sense that there is no code in gcc to
access it.

> > NULL is defined as __null on all platforms now
> 
> Not in DJGPP.  __null causes trouble in C programs.

I'm not talking about C, I'm talking about C++. If djgpp does not use
__null for NULL, then it can't have the features that g++ has on other
systems.

> Why does it need to know that without seeing target header files?  

Well, in theory, it wouldn't need to know - but then it wouldn't be
gcc anymore. What is the problem with having that knowledge in gcc?

> The issue that started this thread is that the DJGPP maintainers don't
> understand the _technical_ reasons why should there be any need for
> GCC to insist on its own, possibly incompatible, definitions.  

If they are incompatible, then the port is broken.

> That is what we are asking to explain.  It is most probable that,
> once we understand the technical issues involved, a number of
> plausible solutions could be suggested.

Well, one reason certainly is that gcc currently does not work this
way, and that it would be a lot of work to change it, and that none of
the regular contributors is going to change it in that direction. So
if you want gcc to work in a different way, you'd have to provide
patches - not only for your target, but for all other targets as well.

> 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.

I'm confused what question you are asking. Are you asking why GCC
installs its headers? I haven't discussed this question in this
message - I thought you are asking why gcc needs builtin knowledge
about the exact definition of certain types and constants.

Regards,
Martin

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019