X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Message-ID: <555AADE6.3030905@iki.fi> Date: Tue, 19 May 2015 06:28:38 +0300 From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: djgpp AT delorie DOT 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> In-Reply-To: <83r3qdemuj.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com On 05/18/2015 09:56 PM, Eli Zaretskii (eliz AT gnu DOT org) wrote: >> Date: Mon, 18 May 2015 19:05:41 +0300 >> From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi)" >> >> On 05/18/2015 06:22 PM, Ozkan Sezer (sezeroz AT gmail DOT com) wrote: >>> On 5/18/15, Eli Zaretskii (eliz AT gnu DOT org) wrote: >>>>> Date: Mon, 18 May 2015 16:06:19 +0300 >>>>> From: "Ozkan Sezer (sezeroz AT gmail DOT com)" >>>>> >>>>> The discussion is about we are pointing to gcc's headers directory >>>>> for allowed includes when building djgpp itself, whereas >>>>> >>>>> (i) we don't need that at all anymore (it was done only to work around >>>>> a gcc builtin problem and it got solved without needing this hack), >>>>> >>>>> (ii) we are building with -nostdinc which means we are self- >>>>> sufficient, and that hack is against this, >>>>> >>>>> (iii) since our DBL_MAX, etc are not compile time constants but symbols, >>>>> and gcc ones are, the binary output of several djgpp functions such as >>>>> strtod, etc, are different with and without gcc-headers hack. >>>>> >>>>> Those are the reasons I am against allowing gcc's headers in djgpp >>>>> build. >>>> AFAIR, -nostdinc means without library headers, but it does not >>>> preclude the headers that are internal to the compiler. > Actually, I think we use -nostdinc to make sure that the header files > come from the library being compiled, not from the installed > production environment. IOW, if you have DJGPP v2.03 installed and > want to build a v2.05 library, you don't want to include, say, stdio.h > that came with v2.03. > > Which means... > >>>> [...] >> Including GCC own headers at first is expected behavior. > ...that including GCC headers is fine, provided that it's needed. GCC includes own headers before DJGPP ones when building user applications. As result several DJGPP headers gets overridden by GCC ones for user applications. float.h is not the only one. GCC provides own version of stdarg.h, stddef.h, stdint.h jne. Removing them would perhaps cause trouble with libstdc++. GCC build process additionally provides a fixing system header files for known incompatibilities by applying corrections to them and placing modified files into directory which is also looked up before system header files. I think it is best to have libc build environment as close to one used after that by users of built library as possible. We need to replace installed DJGPP header ones with ones from version we are building for that. There are however no need to replace GCC headers. It is best to expose and possibly avoid incompatibilities between GCC and DJGPP header files as early as possible instead of hiding them by not including GCC headers. > > But why is it needed? Andris, you installed the change that added > that 2 years ago; do you remember what was the reason for that? Well, we discussed it recently again. Related file (time.h) is now changed not to include GCC own header files directly any more. http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2013/03/05/05:30:15 I would like however like to leave things as they are for reasons mentioned above > >> There is however one other thing: >> >> Unmodified GCC float.h does NOT include next float.h. See >> https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/float.h >> >> For example in my Linux installation there is no float.h in /usr/include. >> >> Including next float.h is an additional hack. I modified GCC float.h and put there >> #ifdef __DJGPP__ >> #include_next >> #endif >> near the begin of GCC float.h. As far I verified there is no float.h in gcc-3.2, but it appears >> in gcc-3.3. The oldest 3.3 DJGPP port deleted/v2gnu/gcc331b.zip already includes DJGPP float.h >> in the begin. >> >> I verified now that for MINGW cross-compiler (I have it installed) "#include_next " is at end of GCC float.h. > In my native MinGW installation, there's no such include_next, FWIW. Fresh download of http://garr.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/4.8/gcc-4.8-win32_4.8.5-20150512.7z shows that MINGW GCC float.h has '#include_next ' at end. Perhaps You have some different older version Andris