Mail Archives: djgpp/2015/05/19/13:15:00
> Sorry, I don't follow. Are you talking about the situation where
> "-nostdinc" is used, like we do in the library build? If so, I think
> only the headers from the explicitly mentioned -I directories are
> included, and if so, the order of the directories mentioned on the
> command line using -I is what determines which headers are included
> first. Isn't that true?
I think they're talking about the fact that gcc will internally add
-I's for its own headers dir, ahead of the system headers dir. This
used to be because system headers were "buggy" and gcc decided to fix
them, or system headers were missing/wrong/incompatible
(i.e. targetted their native compilers) and gcc had to provide
gcc-specific variants.
Since this is the default behavior, this is what users will see when
using djgpp, so that's the case we need to fix. If we do something
different on the command lines in djgpp's libc makefiles to build the
djgpp library, we're just covering up the problem without fixing it.
(note: this may still be the right way to build libc, but only if
there are other reasons to do so)
This is an old problem with djgpp, we've been doing it "the djgpp way"
pretty much since the beginning, since we *also* wanted to be
compatible with Borland C, and the GCC headers weren't. We've even
argued with upstream about which way is right.
Sometimes the gcc headers will #include_next the system headers, but
even then, they often do it at the beginning of the header so they can
"fix" bugs in the system header. We (and apparently mingw ;) would
prefer they #include_next at the end of the header, so we can fix bugs
in the gcc headers. IIRC we used to revisit this problem with every
gcc release, to see if there was a better way yet.
- Raw text -