X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Date: Tue, 19 May 2015 13:14:53 -0400 Message-Id: <201505191714.t4JHEr0B010992@envy.delorie.com> From: DJ Delorie To: djgpp AT delorie DOT com In-reply-to: <83lhgkehn4.fsf@gnu.org> (djgpp@delorie.com) Subject: Re: ANNOUNCE: DJGPP 2.05 beta 1 References: <201505042003 DOT t44K3odg011007 AT delorie DOT com> <554DF584 DOT 4020309 AT iki DOT fi> <55501DAD DOT 1080604 AT iki DOT fi> <55579278 DOT 8090301 AT iki DOT fi> <555829A6 DOT 8010502 AT iki DOT fi> <555870E8 DOT 7040302 AT iki DOT fi> <201505180114 DOT t4I1EiaX017288 AT envy DOT delorie DOT com> <201505181216 DOT t4ICGaKO014123 AT envy DOT delorie DOT com> <83zj52dkns DOT fsf AT gnu DOT org> <555A0DD5 DOT 1010607 AT iki DOT fi> <83r3qdemuj DOT fsf AT gnu DOT org> <555AADE6 DOT 3030905 AT iki DOT f> <83lhgkehn4 DOT fsf AT gnu DOT org> Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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.