Mail Archives: djgpp/2015/05/18/23:28:55
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)" <djgpp AT delorie DOT com>
>>
>> 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) <djgpp AT delorie DOT com> wrote:
>>>>> Date: Mon, 18 May 2015 16:06:19 +0300
>>>>> From: "Ozkan Sezer (sezeroz AT gmail DOT com)" <djgpp AT delorie 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 <float.h>
>> #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 <float.h>" 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 <float.h>' at end. Perhaps You have some different
older version
Andris
- Raw text -