Mail Archives: djgpp/2015/05/19/13:29:26
> > 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.
>
> Is that true even with -nostdinc?
The argument is that we can't rely on that, because the users won't be
using it.
The answer, however, is no. With --nostdinc, neither gcc's nor (I
assume, since I'm testing on Linux) djgpp's implicit includes are
included in the search list.
> Yes, I agree. So if we no longer have a reason to include GCC's
> headers while building the library, we should remove that inclusion
> from makefile.inc, I think.
Exception: if the "reason" is "the headers are broken", then we should
instead fix the headers. Otherwise, users will not get the same
headers as libc, and will/may still see the broken behavior.
> It's AFAIK the job of a platform maintainer for GCC,
The #include_next's are typically available for all platforms, unless
an exception is made. That complicates things upstream.
> but I'm no longer sure what exactly is the status of DJGPP support
> in GCC. Do they consider us a dead platform? Debug info has been
> semi-broken for years.
We (Andris :) maintain our own port with some djgpp-specific changes
(like codegen) pushed upstream and others (like dos-isms) not.
What's wrong with the debug info?
- Raw text -