Mail Archives: djgpp/2015/05/18/12:05:52
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.
>>
> See below,
>
>> IOW, I'm not sure I understand the problem you have with what we do.
>> Can you elaborate?
>>
> I thought that I elaborated enough in the whole thread, but here goes.
> Get the cvs, compile normally under src/. Make a backup copy of
> src/libc/ansi/stdlib/strtod.d and then do the following:
>
> Index: makefile.inc
> ===================================================================
> RCS file: /cvs/djgpp/djgpp/src/makefile.inc,v
> retrieving revision 1.16
> diff -u -r1.16 makefile.inc
> --- makefile.inc 30 Apr 2015 18:50:42 -0000 1.16
> +++ makefile.inc 18 May 2015 15:15:30 -0000
> @@ -51,7 +51,7 @@
>
> # Find GCC own include directory and add it to CFLAGS
> GCC_INC_DIR := $(shell $(CROSS_GCC) -print-file-name=include)
> -CFLAGS += -I$(GCC_INC_DIR)
> +#CFLAGS += -I$(GCC_INC_DIR)
>
> # Pass defines as compiler/assembler switches
> CFLAGS += -DGAS_MAJOR=$(GAS_MAJOR)
>
> Now do a make clean, recompile and compare the old and new strtod.d:
>
> --- strtod.d.bak
> +++ strtod.d
> @@ -1,7 +1,6 @@
> strtod.o: strtod.c ../../../../include/libc/stubs.h \
> ../../../../include/locale.h ../../../../include/math.h \
> ../../../../include/stdlib.h ../../../../include/sys/djtypes.h \
> - /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/include/float.h \
> ../../../../include/float.h ../../../../include/errno.h \
> ../../../../include/ctype.h ../../../../include/inlines/ctype.ha \
> ../../../../include/inlines/ctype.hp \
>
> As you see, -nostdinc does prevent compiler's own headers from being
> used. But with current cvs as it is, we are telling the compiler to
> do use its own headers: Not a good idea IMO.
>
>
Including GCC own headers at first is expected behavior.
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.
Maybe we should do in the same way. In that way DJGPP definitions would override GCC ones instead
of doing otherwise.
Andris
- Raw text -