Mail Archives: djgpp-workers/2000/07/18/14:44:35
> > 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 -