X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=wTo8IH4nGCnHbRWRMrRKM7XsbG/m/zMhQ+aAq24834Y=;
	b=Sw/nwssoqJPhVkW0uChcaKomu00fSvgW7MsMsCyRYTp5GaaSZxTL2BhRmOqHl+nHIr
	jlv7wBjIw6Mn2xsYLxWzV6Fl6zN8GDKHDFQ9imK/BIpLJvOxcWWm3xvKYm1erVEHrxMm
	1+Q3EVgrLc3Qh801/T3m99cO2S+NARmv/4U21PYJP1GgGllMjziiU4NPA5sDMdyl9pPn
	fswVlnudqzAH/fDsmtqFWMewF3GOYFay3aywtClnI7Of+r/lvosUeB0LeCO14FZoL3ig
	9ZSfU3JJ74mntMU+kAg1taP4/NEZft2gQ3edsSGaJjJIMsZPmtVQVqj2Akjg6kkLNLO7
	kouQ==
MIME-Version:	1.0
X-Received:	by 10.107.12.93 with SMTP id w90mr17985315ioi.10.1431965546412;
	Mon, 18 May 2015 09:12:26 -0700 (PDT)
In-Reply-To:	<555A0DD5.1010607@iki.fi>
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>
	<555A0DD5 DOT 1010607 AT iki DOT fi>
Date:	Mon, 18 May 2015 19:12:26 +0300
Message-ID:	<CAA2C=vDViDW_U2NmAYnO=HtTZ+=aw68pg0=MKc=bu-DaUQxB9g@mail.gmail.com>
Subject:	Re: ANNOUNCE: DJGPP 2.05 beta 1
From:	"Ozkan Sezer (sezeroz AT gmail DOT com)" <djgpp AT delorie DOT com>
To:	djgpp AT delorie DOT com
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 5/18/15, Andris Pavenis (andris DOT pavenis AT iki DOT fi) <djgpp AT delorie DOT com> wrote:
> 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.
>

Which djgpp didn't do for 20 years but only since recently,
for why I cannot understand

> 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.
>

That is reasonable: even if djgpp build wouldn't incude gcc's headers
the user programs do, and overriding gcc would be the right thing IMO

- Raw text -