X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Message-ID: <555A0DD5.1010607@iki.fi>
Date: Mon, 18 May 2015 19:05:41 +0300
From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi)" <djgpp AT delorie DOT com>
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>	<CAA2C=vAjN-HamFRWCQak=QF_NPjR5-TBYZw1U5707MO0b=qXkw AT mail DOT gmail DOT com>	<554DF584 DOT 4020309 AT iki DOT fi>	<CAA2C=vDaOJb_RW2bQEFoM_cqwp7yhzwX-CB328r5GCCi6XcooA AT mail DOT gmail DOT com>	<55501DAD DOT 1080604 AT iki DOT fi>	<CAA2C=vAvMW-yquZLSN=Z39NU24Kqf7urjan90801i7BDTdqOvQ AT mail DOT gmail DOT com>	<55579278 DOT 8090301 AT iki DOT fi>	<CAA2C=vBaQKzmch_buxFm20DJLcG+zv6d6803+qMEx=baA4Frog AT mail DOT gmail DOT com>	<555829A6 DOT 8010502 AT iki DOT fi>	<CAA2C=vA73qPvoDFytp3FeW6bCD1-XuGsFFoDinoKn2KYY1fkow AT mail DOT gmail DOT com>	<555870E8 DOT 7040302 AT iki DOT fi>	<CAA2C=vDhD6BJj89o1i0FRd2U0H4bTpGGN4zH6qs7FJKxzqhuQg AT mail DOT gmail DOT com>	<201505180114 DOT t4I1EiaX017288 AT envy DOT delorie DOT com>	<CAA2C=vCyrQ_+Yq6XsRD-UO4r=j9WoGGiXoqQFrkbiEQpzX+=MA AT mail DOT gmail DOT com>	<201505181216 DOT t4ICGaKO014123 AT envy DOT delorie DOT com>	<CAA2C=vCk5MY74z+HNVzzdLByg71Y_9ObK-1jPxJ_KF8eqRDZMQ AT mail DOT gmail DOT com>	<83zj52dkns DOT fsf AT gnu DOT org> <CAA2C=vAPcN+MKC_2tcZqVmo9gvF2Cxdo+K+-qfKaNrQuCkMnEw AT mail DOT gmail DOT com>
In-Reply-To: <CAA2C=vAPcN+MKC_2tcZqVmo9gvF2Cxdo+K+-qfKaNrQuCkMnEw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: 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.
>>
> 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