ANNOUNCE: DJGPP 2.05 beta 1

302 views
Skip to first unread message

Andris Pavenis (andris.pavenis@iki.fi)

unread,
May 4, 2015, 4:04:20 PM5/4/15
to djgpp-a...@delorie.com
This is announcement of DJGPP 2.05 beta 1

It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
(http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
Unfortunately DJGPP v2.04 was never released and old beta version slowly
became almost unusable together with other newer DJGPP packages.

More information about changes in DJGPP 2.05 beta 1 is available at

http://www.delorie.com/djgpp/doc/kb/

both in sections about changes in 2.04 and 2.05. The same information is also
available in file info/kb.inf in djdev205.zip

It needs a lot of testing. Please test it if you have time and/or are
interested in any of the above features. Any level of testing would be
appreciated.

The beta is not available via the Zip Picker interface. You can download it
from here:

ftp://ftp.delorie.com/pub/djgpp/beta/v2

Additionally RPM packages (source and binary packages for i686 and x86_64) are
available from

ftp://ftp.delorie.com/pub/djgpp/rpms

Please see the README file for instructions on how to install the beta:

ftp://ftp.delorie.com/pub/djgpp/beta/v2/readme.1st

You can also download DJGPP 2.05 beta 1 packages from DJGPP mirror sites:

http://www.delorie.com/djgpp/getting.html

Thanks for all who have contributed to development of DJGPP

Andris Pavenis

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 5, 2015, 5:03:27 AM5/5/15
to dj...@delorie.com
On 5/4/15, Andris Pavenis (andris....@iki.fi)
<djgpp-a...@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
> http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.
>

Looking at the commit log of src/makefile.cfg r1.2, we should add the
following to current makefile.cfg, at least for sake of completeness.

Index: makefile.cfg
===================================================================
RCS file: /cvs/djgpp/djgpp/src/makefile.cfg,v
retrieving revision 1.5
diff -u -r1.5 makefile.cfg
--- makefile.cfg 3 May 2015 12:23:14 -0000 1.5
+++ makefile.cfg 5 May 2015 08:25:14 -0000
@@ -8,6 +8,12 @@
MTUNE := -mcpu=i586
IQUOTE := -I. -I-

+ifeq ($(GCC_MAJOR),)
+# very old gcc, e.g. gcc-2.95, fails the above, so we invent a default.
+GCC_MAJOR := 2
+GCC_MINOR := 7
+endif
+
ifeq ($(filter 2 3,$(GCC_MAJOR)),)
# we have gcc >= 4.x
MTUNE := -mtune=i586



> The beta is not available via the Zip Picker interface. You can download it
> from here:
>
> ftp://ftp.delorie.com/pub/djgpp/beta/v2
>
> Additionally RPM packages (source and binary packages for i686 and x86_64)
> are
> available from
>
> ftp://ftp.delorie.com/pub/djgpp/rpms
>
> Please see the README file for instructions on how to install the beta:
>
> ftp://ftp.delorie.com/pub/djgpp/beta/v2/readme.1st
>
> You can also download DJGPP 2.05 beta 1 packages from DJGPP mirror sites:
>
> http://www.delorie.com/djgpp/getting.html
>
> Thanks for all who have contributed to development of DJGPP
>
> Andris Pavenis
>

--
O.S.

RayeR

unread,
May 6, 2015, 8:12:15 AM5/6/15
to
Hi,
thank you for your effort to make final release of djdev 2.05!
Please could you just add log2f macro to INCLUDE/MATH.H that I need for compiling FFMPEG package?
#ifndef log2f
#define log2f(x) (logf(x)/(float)M_LN2)
#endif
I can see that it's placed in INCLUDE/LIBM/MATH.H but this file seems to not be included in my case (or macro not defined) so I added it directly to INCLUDE/MATH.H myself. After this minor fix FFMPEG was compiled without problem and works fine.

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 6, 2015, 8:56:23 AM5/6/15
to dj...@delorie.com
On 5/4/15, Andris Pavenis (andris....@iki.fi)
<djgpp-a...@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
> http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.

include/stdbool.h seems to have some confusion in it,
like defining its stuff, (to wrong things), when __cplusplus
is defined for one. I suggest that we match it to what gcc
itself provides.

--
O.S.

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 7, 2015, 4:09:01 AM5/7/15
to dj...@delorie.com
On 5/4/15, Andris Pavenis (andris....@iki.fi)
<djgpp-a...@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
> http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.

Andris's r1.14 change to src/makefile.ic (to add gcc's own include
directory to CFLAGS) defeats djgpp's float.h DBL_MIN and DBL_MAX
macros: with djgpp's folat.h, they are defined to __dj_double_min
and __dj_double_max symbols, however gcc's float.h undefines them
and redefines them as floatiing point constants. Therefore, with
and without the r1.14 change to src/makefile.inc being in effect,
the binary output of several sources, such as strtod.c, differ.
Not noticed before, or not cared about?

(BTW, why are we defining DBL_MIN/_MAX as __dj_double_min/_max and
not as constants?)

DJ Delorie

unread,
May 7, 2015, 1:41:39 PM5/7/15
to dj...@delorie.com

> (BTW, why are we defining DBL_MIN/_MAX as __dj_double_min/_max and
> not as constants?)

This way we get the exact bit pattern we want without worrying if
the compiler will parse a constant correctly.

Andris Pavenis (andris.pavenis@iki.fi)

unread,
May 8, 2015, 12:52:04 PM5/8/15
to dj...@delorie.com
On 05/08/2015 07:12 PM, Ozkan Sezer (sez...@gmail.com) wrote:
> On 5/4/15, Andris Pavenis (andris....@iki.fi)
> <djgpp-a...@delorie.com> wrote:
>> This is announcement of DJGPP 2.05 beta 1
>>
>> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
>> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
>> Unfortunately DJGPP v2.04 was never released and old beta version slowly
>> became almost unusable together with other newer DJGPP packages.
>>
>> More information about changes in DJGPP 2.05 beta 1 is available at
>>
>> http://www.delorie.com/djgpp/doc/kb/
>>
>> both in sections about changes in 2.04 and 2.05. The same information is
>> also
>> available in file info/kb.inf in djdev205.zip
>>
>> It needs a lot of testing. Please test it if you have time and/or are
>> interested in any of the above features. Any level of testing would be
>> appreciated.
> Attached are two tiny patches:
>
> - ioctl-va_end.patch: adds missing va_end to unix ioctl case.
>
> - no-Wno-error.patch: removes -Wno-error special cases from
> ioctl.c and fcntl.c build rules. Warnings seem to have been cured
> since ioctl.c r1.8 and fcntl.c r1.10.
Thanks. I applied them.

Andris

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 11, 2015, 4:13:14 AM5/11/15
to djgpp, Andris Pavenis
[adding list back to CC]

On 5/11/15, Andris Pavenis <andris....@iki.fi> wrote:
[...]
>
> You also mentioned stdbool.h and float.h issues (no patches yet). I do not
> think we should touch
> them now before actual 2.05 release. Also including GCC own header and ones
> modified by
> fixincludes in GCC build process before system ones is way how it is done
> (not only for DJGPP but also
> for other targets).

For float.h issue: Well, -nostdinc means -nostdinc so I think that we
should be consistent with it. For gcc >= 4.8 maybe define our _rdtsc()
as __builtin_ia32_rdtsc()?? What was the exact problem with _rdtsc()
with gcc >= 4.8?

For stdbool.h: it defines bool, true and false which are native to C++
and therefore broken. Gcc's own stdbool.h is good of course, so why
don't we copy from it?

--
O.S.

Andris Pavenis (andris.pavenis@iki.fi)

unread,
May 16, 2015, 2:54:56 PM5/16/15
to dj...@delorie.com
On 05/11/2015 11:12 AM, Ozkan Sezer (sez...@gmail.com) wrote:
> [adding list back to CC]
>
> On 5/11/15, Andris Pavenis <andris....@iki.fi> wrote:
> [...]
>> You also mentioned stdbool.h and float.h issues (no patches yet). I do not
>> think we should touch
>> them now before actual 2.05 release. Also including GCC own header and ones
>> modified by
>> fixincludes in GCC build process before system ones is way how it is done
>> (not only for DJGPP but also
>> for other targets).
> For float.h issue: Well, -nostdinc means -nostdinc so I think that we
> should be consistent with it. For gcc >= 4.8 maybe define our _rdtsc()
> as __builtin_ia32_rdtsc()?? What was the exact problem with _rdtsc()
> with gcc >= 4.8?
If we define own _rdtsc() we get duplicate definition of it when GCC own header x86intrin.h is also
included (for new GCC version). That was the reason why I used GCC defined function instead
of DJGPP one.

There is additional problem that GCC header files *intrin.h are not OK when -Wcast-qual is being used.
The problem is triggered when building DJGPP tests but not when building libc itself.

Andris

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 16, 2015, 3:56:42 PM5/16/15
to dj...@delorie.com
Can you please show the error or warning messages form each
problematic case?

I tried to reproduce the problems: commented out the -I$(GCC_INC_DIR)
additions to CFLAGS in both src/ and tests/makefile.in, compiled src
using my gcc5 cross-compiler and got no errors or warnings for _rdtsc()
Tried compiling the test programs: since I am on linux, had to do some
voodoo in the makefiles by changing gcc and ld to cross- versions and
by replacing rem.com with /bin/true, they just compiled. (of course,
no run tests, and found other issues, but no _rdtsc() issues.)

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 16, 2015, 4:10:24 PM5/16/15
to dj...@delorie.com
Compilation of the test programs revealed the following
(There were some other warnings, but much less important
or unimportant.)

* tests/libc/posix/fcntl/makef3gb.c
makef3gb.c: In function 'main':
makef3gb.c:44:47: warning: iteration 512000u invokes undefined
behavior [-Waggressive-loop-optimizations]
for (i = 0; i <= BIGBUFSIZE; i++) bigbuf[i] = (char) i;
^
makef3gb.c:44:3: note: containing loop
for (i = 0; i <= BIGBUFSIZE; i++) bigbuf[i] = (char) i;
^

Just fixed in makef3gb.c r1.2 by changing comparison from le to lt.


* include/math.h (sincos) :
In file included from strtold1.c:4:0:
./../../../include/math.h:261:8: warning: conflicting types for
built-in function 'sincos'
void sincos(double *_cos, double *_sin, double _x);
^
In file included from strtod1.c:4:0:
./../../../include/math.h:261:8: warning: conflicting types for
built-in function 'sincos'
void sincos(double *_cos, double *_sin, double _x);
^

My linux man page for sincos() has the prototype:
void sincos(double x, double *sin, double *cos);
The djgpp version has the parameters in reversed order.
The library compilation doesn't warn because the source
is in assembly not C. What to do with this?

--
O.S.

Andris Pavenis (andris.pavenis@iki.fi)

unread,
May 17, 2015, 1:40:11 AM5/17/15
to dj...@delorie.com
On 05/16/2015 10:56 PM, Ozkan Sezer (sez...@gmail.com) wrote:
> On 5/16/15, Andris Pavenis (andris....@iki.fi) <dj...@delorie.com> wrote:
>> with gcc >= 4.8?
>> If we define own _rdtsc() we get duplicate definition of it when GCC own
>> header x86intrin.h is also
>> included (for new GCC version). That was the reason why I used GCC defined
>> function instead
>> of DJGPP one.
>>
>> Can you please show the error or warning messages form each
>> problematic case?
>>
>> I tried to reproduce the problems: commented out the -I$(GCC_INC_DIR)
>> additions to CFLAGS in both src/ and tests/makefile.in, compiled src
>> using my gcc5 cross-compiler and got no errors or warnings for _rdtsc()
>> Tried compiling the test programs: since I am on linux, had to do some
>> voodoo in the makefiles by changing gcc and ld to cross- versions and
>> by replacing rem.com with /bin/true, they just compiled. (of course,
>> no run tests, and found other issues, but no _rdtsc() issues.)
I do not remember exactly with which piece of software I got this problem with _rdtsc

With DJGPP own _rdtsc the following 2 includes causes compile error:

#include <x86intrin.h>
#include <time.h>

One should be able to use SSE/MMX/AVX instructions with DJGPP.

ia32intrin.h defines _rdtsc() and as result one gets duplicate definition if one includes
x86intrin.h before time.h without that change (including x86intrin.h instead
of defining _rdtsc()).

There is fortunately another way without including x86intrin.h from time.h:

ia86intrin.h contains '#define _rdtsc() __rdtsc()' and it defines __rdtsc as an inline function.
One could also undefine _rdtsc before defining our own.

Andris

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 17, 2015, 4:45:28 AM5/17/15
to dj...@delorie.com
How about something like the following: when building djgpp, keep our
version of _rdtsc(), but for users defer to gcc's version:

Index: include/time.h
===================================================================
RCS file: /cvs/djgpp/djgpp/include/time.h,v
retrieving revision 1.16
diff -u -r1.16 time.h
--- include/time.h 2 May 2015 07:31:49 -0000 1.16
+++ include/time.h 17 May 2015 08:14:37 -0000
@@ -112,7 +112,7 @@
void tzsetwall(void);
uclock_t uclock(void);

-#if ((__GNUC__ == 4 && __GNUC_MINOR__ >= 8) || (__GNUC__ > 4))
+#if !defined(_IN_DJBUILD) && ((__GNUC__ == 4 && __GNUC_MINOR__ >= 8)
|| (__GNUC__ > 4))

/* GCC-4.8 has own built-in _rdtsc for ix86. Therefore use it insted
of DJGPP one. */
#include <x86intrin.h>
Index: src/makefile.cfg
===================================================================
RCS file: /cvs/djgpp/djgpp/src/makefile.cfg,v
retrieving revision 1.6
diff -u -r1.6 makefile.cfg
--- src/makefile.cfg 11 May 2015 11:00:14 -0000 1.6
+++ src/makefile.cfg 17 May 2015 08:14:37 -0000
@@ -46,16 +46,17 @@
@./misc.exe echo - "-Wundef" >>gcc.opt
@./misc.exe echo - "-Wcast-align" >>gcc.opt
@./misc.exe echo - "-Wsign-compare" >>gcc.opt
+ @./misc.exe echo - "-D_IN_DJBUILD" >>gcc.opt
@./misc.exe echo - "-nostdinc" >>gcc.opt
@./misc.exe echo - "$(IQUOTE)" >>gcc.opt

-
gcc-l.opt: makefile.cfg
@./misc.exe echo - "-MD" >gcc-l.opt
@./misc.exe echo - "-O2" >>gcc-l.opt
@./misc.exe echo - "$(MTUNE)" >>gcc-l.opt
@./misc.exe echo - "-march=i386" >>gcc-l.opt
@./misc.exe echo - "-Wall" >>gcc-l.opt
+ @./misc.exe echo - "-D_IN_DJBUILD" >>gcc-l.opt
@./misc.exe echo - "-nostdinc" >>gcc-l.opt
@./misc.exe echo - "$(IQUOTE)" >>gcc-l.opt

Index: src/makefile.inc
===================================================================
RCS file: /cvs/djgpp/djgpp/src/makefile.inc,v
retrieving revision 1.16
diff -u -r1.16 makefile.inc
--- src/makefile.inc 30 Apr 2015 18:50:42 -0000 1.16
+++ src/makefile.inc 17 May 2015 08:14:37 -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)

If this is acceptable (and works for you+everyone), a similar change
needs to be done in the tests makefiles. (I've done that locally and
cross-built the libc test programs without errors.)

--
O.S.

Andris Pavenis (andris.pavenis@iki.fi)

unread,
May 17, 2015, 6:44:07 AM5/17/15
to dj...@delorie.com
I already committed change which avoid to include x86intrin.h at all. So also
-Wcat-qual related warnings from GCC MMX/SSE/AVX related stuff no more matter.

About removing GCC own include directory from header files search path:

I would prefer not to do it. The idea of -nostdinc was to tell GCC not to look-up
installed DJGPP header files but use ones from build directory added from command line.
GCC include files is a different stuff and should not be removed from look-up.
It is better to have them included in the same way as it is done when building
user applications.

Andris

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 17, 2015, 7:00:21 AM5/17/15
to dj...@delorie.com
Applied the following to dxe3res.c as of r1.4:

make dxe3res to build and run on unix:
- include sys/dxe.h from the local source tree only,
- do the LD_LIBRARY_PATH lookup only for DOS builds.

Index: src/dxe/dxe3res.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/dxe/dxe3res.c,v
retrieving revision 1.3
diff -u -p -r1.3 dxe3res.c
--- src/dxe/dxe3res.c 16 Jun 2013 01:15:12 -0000 1.3
+++ src/dxe/dxe3res.c 17 May 2015 10:37:50 -0000
@@ -12,7 +12,7 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
-#include <sys/dxe.h>
+#include "../../include/sys/dxe.h"

#define VERSION "1.0"

@@ -288,7 +288,7 @@ static char *gettables(const char *filen
{
FILE *f;
char *table;
-
+#ifdef __DJGPP__
char *scan;
char tempfn[FILENAME_MAX]; /* Temporary filename */

@@ -324,7 +324,7 @@ static char *gettables(const char *filen
return NULL;
}
found:
-
+#endif /* __DJGPP__ */
if ((f = fopen(filename, "rb")) != NULL)
{
if (readf(dxehdr, sizeof(dxe3_header), f, 0) && (isdxe(dxehdr) == 3))

--
O.S.

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 17, 2015, 7:00:25 AM5/17/15
to dj...@delorie.com
OK,

> About removing GCC own include directory from header files search path:
>
> I would prefer not to do it. The idea of -nostdinc was to tell GCC not to
> look-up
> installed DJGPP header files but use ones from build directory added from
> command line.
> GCC include files is a different stuff and should not be removed from
> look-up.
> It is better to have them included in the same way as it is done when
> building
> user applications.
>
> Andris
>

As I said in earlier in this thread, gcc's own headers (e.g. float.h) undefine
stuff from djgpp's headers and the resulting binaries differ, e.g. for DBL_MIN
and DBL_MAX. I don't like this. DJ, what do you think?

--
O.S.

DJ Delorie

unread,
May 17, 2015, 9:14:57 PM5/17/15
to dj...@delorie.com

If gcc and djgpp have differing values for DBL_MIN and DBL_MAX, one of
them is wrong. Do we know which one?

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 18, 2015, 5:43:41 AM5/18/15
to dj...@delorie.com, DJ Delorie
On 5/18/15, DJ Delorie <d...@delorie.com> wrote:
>
> If gcc and djgpp have differing values for DBL_MIN and DBL_MAX, one of
> them is wrong. Do we know which one?
>

* gcc float.h: (same for gcc3.4 and gcc5.1)
#undef FLT_MAX
#undef DBL_MAX
#undef LDBL_MAX
#define FLT_MAX __FLT_MAX__
#define DBL_MAX __DBL_MAX__
#define LDBL_MAX __LDBL_MAX__

* gcc builtin defines:
#define __FLT_MAX__ 3.40282347e+38F /* gcc3.4 */
#define __FLT_MAX__ 3.40282346638528859812e+38F /* gcc5.1 */
#define __DBL_MAX__ 1.7976931348623157e+308 /* gcc3.4 */
#define __DBL_MAX__ ((double)1.79769313486231570815e+308L) /* gcc5.1 */
#define __LDBL_MAX__ 1.18973149535723176502e+4932L /* gcc3.4 */
#define __LDBL_MAX__ 1.18973149535723176502e+4932L /* gcc5.1 */

* dj float.h:
extern double __dj_double_max;
#define DBL_MAX __dj_double_max

* libc/ansif/float/float_dx.c:
double_t __dj_double_max = { 0xffffffffU, 0xfffff, 0x7fe, 0x0 };
* libc/ansif/float/float_fx.c:
float_t __dj_float_max = { 0x7fffff, 0xfe, 0x0 };

DJ Delorie

unread,
May 18, 2015, 8:16:50 AM5/18/15
to dj...@delorie.com

I tested this with Linux gcc 5.1 and got the same bit patterns for
both cases:

typedef struct {
unsigned mantissal:32;
unsigned mantissah:20;
unsigned exponent:11;
unsigned sign:1;
} double_t;
double gdm = ((double)1.79769313486231570815e+308L);
double_t ddm = { 0xffffffffU, 0xfffff, 0x7fe, 0x0 };

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 18, 2015, 9:06:31 AM5/18/15
to dj...@delorie.com
On 5/18/15, DJ Delorie <d...@delorie.com> wrote:
>
OK, if we are good with gcc defines then change your float.h accordingly,
but that's not my point.

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.

Eli Zaretskii (eliz@gnu.org)

unread,
May 18, 2015, 10:26:44 AM5/18/15
to DJ Delorie, dj...@delorie.com
> Date: Mon, 18 May 2015 08:16:36 -0400
> From: DJ Delorie <d...@delorie.com>
But with the one in DJGPP's headers, we are not at the mercy of the
compiler's bugs^H^H^H^Hfeatures...

Eli Zaretskii (eliz@gnu.org)

unread,
May 18, 2015, 10:29:13 AM5/18/15
to dj...@delorie.com
> Date: Mon, 18 May 2015 16:06:19 +0300
> From: "Ozkan Sezer (sez...@gmail.com)" <dj...@delorie.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.

IOW, I'm not sure I understand the problem you have with what we do.
Can you elaborate?

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 18, 2015, 11:22:48 AM5/18/15
to dj...@delorie.com
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.

Andris Pavenis (andris.pavenis@iki.fi)

unread,
May 18, 2015, 12:05:52 PM5/18/15
to dj...@delorie.com
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


Eli Zaretskii (eliz@gnu.org)

unread,
May 18, 2015, 12:09:51 PM5/18/15
to dj...@delorie.com
> Date: Mon, 18 May 2015 18:22:35 +0300
> From: "Ozkan Sezer (sez...@gmail.com)" <dj...@delorie.com>
>
> --- 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.

Are you sure the compiler doesn't use that header when it sees
"-nostdinc"? Could it be that it just doesn't put that header into
the dependencies?

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 18, 2015, 12:12:35 PM5/18/15
to dj...@delorie.com
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

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 18, 2015, 12:13:18 PM5/18/15
to dj...@delorie.com
On 5/18/15, Eli Zaretskii (el...@gnu.org) <dj...@delorie.com> wrote:
Joke, right?

Eli Zaretskii (eliz@gnu.org)

unread,
May 18, 2015, 12:49:55 PM5/18/15
to dj...@delorie.com
> Date: Mon, 18 May 2015 19:13:12 +0300
> From: "Ozkan Sezer (sez...@gmail.com)" <dj...@delorie.com>
>
> >> --- 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.
> >
> > Are you sure the compiler doesn't use that header when it sees
> > "-nostdinc"? Could it be that it just doesn't put that header into
> > the dependencies?
> >
>
> Joke, right?

You mean, you are joking by asking whether I am?

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 18, 2015, 12:59:15 PM5/18/15
to dj...@delorie.com
On 5/18/15, Eli Zaretskii (el...@gnu.org) <dj...@delorie.com> wrote:
This is ridiculous.. To answer your original question, yes I am sure.
Did you even try to reproduce what I said? If you ever bother to do
so, you can even add -save-temps to the cflags and compare the
assembler outputs to see what I am saying.

Eli Zaretskii (eliz@gnu.org)

unread,
May 18, 2015, 1:23:15 PM5/18/15
to dj...@delorie.com
> Date: Mon, 18 May 2015 19:59:05 +0300
> From: "Ozkan Sezer (sez...@gmail.com)" <dj...@delorie.com>
>
> On 5/18/15, Eli Zaretskii (el...@gnu.org) <dj...@delorie.com> wrote:
> >> Date: Mon, 18 May 2015 19:13:12 +0300
> >> From: "Ozkan Sezer (sez...@gmail.com)" <dj...@delorie.com>
> >>
> >> >> --- 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.
> >> >
> >> > Are you sure the compiler doesn't use that header when it sees
> >> > "-nostdinc"? Could it be that it just doesn't put that header into
> >> > the dependencies?
> >> >
> >>
> >> Joke, right?
> >
> > You mean, you are joking by asking whether I am?
>
> This is ridiculous.

Why "ridiculous"? You asked questions, so I'm trying to help you
figure things out. You can ignore what I say if you think it's
irrelevant, or doesn't help you. But this reaction of yours is just
plain rude, for no good reason (and not for the first time, either).
I'm trying to help you as best I can, I don't think I deserve this
attitude of yours, even if what I say sound preposterous to you.

> Did you even try to reproduce what I said?

Did you even care to ask if I can set that up, or have enough time to
do so? Why should that be a prerequisite for trying to think aloud
about the problem _you_ are asking questions about?

Or if that _is_ a prerequisite, please say so loud and clear, and I
won't bother answering you if I cannot try it myself.

> If you ever bother to do so, you can even add -save-temps to the
> cflags and compare the assembler outputs to see what I am saying.

I believe you. I didn't ask that question because I thought you were
lying, or didn't know what you were talking about. I asked it because
these issues are complicated, and sometimes we tend to think we
understand something, when in fact we miss some subtle aspects. Like
in that example with _open and O_BINARY a couple of days ago.

So please don't assume that every question like that is a challenge of
your integrity or a personal attack on your intelligence. It's just a
normal way of discussing a complicated issue, about which _you_ asked
questions. I'm not attacking you, I'm trying to help, goddamit!

Eli Zaretskii (eliz@gnu.org)

unread,
May 18, 2015, 2:56:43 PM5/18/15
to dj...@delorie.com
> Date: Mon, 18 May 2015 19:05:41 +0300
> From: "Andris Pavenis (andris....@iki.fi)" <dj...@delorie.com>
>
> On 05/18/2015 06:22 PM, Ozkan Sezer (sez...@gmail.com) wrote:
> > On 5/18/15, Eli Zaretskii (el...@gnu.org) <dj...@delorie.com> wrote:
> >>> Date: Mon, 18 May 2015 16:06:19 +0300
> >>> From: "Ozkan Sezer (sez...@gmail.com)" <dj...@delorie.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.

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?

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

Andris Pavenis (andris.pavenis@iki.fi)

unread,
May 18, 2015, 11:28:56 PM5/18/15
to dj...@delorie.com
> ...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


rug...@gmail.com

unread,
May 18, 2015, 11:46:44 PM5/18/15
to
Hi,

On Monday, May 18, 2015 at 1:56:43 PM UTC-5, Andris Pavenis (andris....@spam.sux) wrote:
> > Date: Mon, 18 May 2015 19:05:41 +0300
> > From: "Andris Pavenis (andris....@spam.sux)" <dj...@spam.sux>
>
> In my native MinGW installation, there's no such include_next, FWIW.

Just FYI, somewhat off-topic, but as you can see, Google Groups is
misattributing this message, making it seem like Andris is talking
to himself. :-P

Rod Pemberton

unread,
May 19, 2015, 3:27:58 AM5/19/15
to
On Mon, 18 May 2015 13:22:57 -0400, Eli Zaretskii (el...@gnu.org)
<dj...@delorie.com> wrote:

> [...] You asked questions, so I'm trying to help you
> figure things out. You can ignore what I say if you think it's
> irrelevant, or doesn't help you. But this reaction of yours is just
> plain rude, for no good reason (and not for the first time, either).
> I'm trying to help you as best I can, I don't think I deserve this
> attitude of yours, even if what I say sound preposterous to you.

Sigh, here we go again with Eli ...

Eli, we all know you are or once were a significant contributor to
DJGPP, who should know much about DJGPP's internals. However, you
eventually respond this way to *EVERYBODY* ... Usually, someone spends
an immense amount of time understanding a complicated issue for which
there is no documentation, only for you to say it doesn't work that
way in DJGPP without any further explanation of why it doesn't, or you
rudely ask them if they're sure after they just spent a huge amount of
time understanding the issue. So, everybody gets angry with you ...
What did you expect to happen? You then blame the other person for
being angry with you or for being rude, and then you insist you were
just attempting to help, or to help the other person understand an
issue they now know extra-thoroughly. From my recollection, just
about everyone who has conversed with you for more than a post or
two becomes angry with you. Given that so many people here have been
angered by you in about the _decade_ I've been reading and posting
here, have you even remotely considered that it's your response to or
perception of others which is abnormal? ... D.J. and Charles seem
to be the only people who haven't taken offense at one time or another
to you in all that time, but you don't respond that way to them, even
when D.J. has no knowledge of the issue at hand.

HTH,


Rod Pemberton

--
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?

Eli Zaretskii (eliz@gnu.org)

unread,
May 19, 2015, 11:01:32 AM5/19/15
to dj...@delorie.com
> Date: Tue, 19 May 2015 06:28:38 +0300
> From: "Andris Pavenis (andris....@iki.fi)" <dj...@delorie.com>
>
> >> 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.

Sorry, I don't follow. Are you talking about the situation where
"-nostdinc" is used, like we do in the library build? If so, I think
only the headers from the explicitly mentioned -I directories are
included, and if so, the order of the directories mentioned on the
command line using -I is what determines which headers are included
first. Isn't that true?

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

I don't think this is a practical alternative. There should be a way
of building a library without overriding the production environment.
E.g., what if one wants to build a snapshot, or a version of the
development code that is not yet ready for prime time? You cannot
tell users to break their production environment.

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

So this additional inclusion is not needed anymore, I guess.

> I would like however like to leave things as they are for reasons
> mentioned above

I don't yet understand those reasons, so I cannot tell if I agree.

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

I'm using the last official mingw.org distribution of GCC, whcih is of
GCC 4.8.1.

DJ Delorie

unread,
May 19, 2015, 1:05:18 PM5/19/15
to dj...@delorie.com

> Sigh, here we go again with Eli ...

Sigh, here we go again with Rod ...

> However, you eventually respond this way to *EVERYBODY* ...

I re-read the thread, and Eli asked a perfectly valid (if unexpected)
question, and rather than respect the question, the OP disrespected
the poster. Given that the issue is complex and yet still not fixed,
suggestions for the rare-but-possible cases are justified. The only
people who should be insulted by such suggestions are those who have
already solved the problem, or already tried the advice indicated, not
those who are still trying to figure it out.

We've seen a lot of wierd bugs in the past, so if we suggest something
completely out of the blue, it's probably because it's happened
before.

> rudely

So you see it. I don't.

> ask them if they're sure

Or, in this case, if they've considered the case where the compiler
might be lying to them about what it's doing.

> after they just spent a huge amount of time understanding the issue.

Yet still not solving.

> perception of others which is abnormal? ... D.J. and Charles seem

If you've been around all this time, why don't you spell my name
correctly yet? "I'm insulted, and assume you're doing it on purpose
just to annoy me[*]." Take the time to be precise in what you write,
and consider all the ways it can be read, and perhaps you'll have less
conflict with people who don't know you. It's a lesson I've learned
the hard way over the decades. Heck, I can't even tell when my
brother is joking in an email, and I've known him all his life.

[*] I'm not insulted, I assume you're innocently mistaken, just using
it as an example of how people can mis-read others' posts.

> to be the only people who haven't taken offense at one time or another
> to you in all that time, but you don't respond that way to them, even
> when D.J. has no knowledge of the issue at hand.

I've gotten all sorts of responses from Eli. Often, he's right. He's
earned the right to suggest stupid things to me, because sometimes the
stupid is on my side.

Also, I've learned to look at conversations from the other point of
view, in case it's just a misunderstanding or miscommunication.
Remember, Eli's native language is *not* English, despite how well he
speaks it.

> HTH,

It doesn't.

DJ Delorie

unread,
May 19, 2015, 1:15:01 PM5/19/15
to dj...@delorie.com

> Sorry, I don't follow. Are you talking about the situation where
> "-nostdinc" is used, like we do in the library build? If so, I think
> only the headers from the explicitly mentioned -I directories are
> included, and if so, the order of the directories mentioned on the
> command line using -I is what determines which headers are included
> first. Isn't that true?

I think they're talking about the fact that gcc will internally add
-I's for its own headers dir, ahead of the system headers dir. This
used to be because system headers were "buggy" and gcc decided to fix
them, or system headers were missing/wrong/incompatible
(i.e. targetted their native compilers) and gcc had to provide
gcc-specific variants.

Since this is the default behavior, this is what users will see when
using djgpp, so that's the case we need to fix. If we do something
different on the command lines in djgpp's libc makefiles to build the
djgpp library, we're just covering up the problem without fixing it.
(note: this may still be the right way to build libc, but only if
there are other reasons to do so)

This is an old problem with djgpp, we've been doing it "the djgpp way"
pretty much since the beginning, since we *also* wanted to be
compatible with Borland C, and the GCC headers weren't. We've even
argued with upstream about which way is right.

Sometimes the gcc headers will #include_next the system headers, but
even then, they often do it at the beginning of the header so they can
"fix" bugs in the system header. We (and apparently mingw ;) would
prefer they #include_next at the end of the header, so we can fix bugs
in the gcc headers. IIRC we used to revisit this problem with every
gcc release, to see if there was a better way yet.

Eli Zaretskii (eliz@gnu.org)

unread,
May 19, 2015, 1:24:02 PM5/19/15
to DJ Delorie, dj...@delorie.com
> Date: Tue, 19 May 2015 13:14:53 -0400
> From: DJ Delorie <d...@delorie.com>
>
> > Sorry, I don't follow. Are you talking about the situation where
> > "-nostdinc" is used, like we do in the library build? If so, I think
> > only the headers from the explicitly mentioned -I directories are
> > included, and if so, the order of the directories mentioned on the
> > command line using -I is what determines which headers are included
> > first. Isn't that true?
>
> I think they're talking about the fact that gcc will internally add
> -I's for its own headers dir, ahead of the system headers dir.

Is that true even with -nostdinc?

> Since this is the default behavior, this is what users will see when
> using djgpp, so that's the case we need to fix. If we do something
> different on the command lines in djgpp's libc makefiles to build the
> djgpp library, we're just covering up the problem without fixing it.
> (note: this may still be the right way to build libc, but only if
> there are other reasons to do so)

Yes, I agree. So if we no longer have a reason to include GCC's
headers while building the library, we should remove that inclusion
from makefile.inc, I think.

> This is an old problem with djgpp, we've been doing it "the djgpp way"
> pretty much since the beginning, since we *also* wanted to be
> compatible with Borland C, and the GCC headers weren't. We've even
> argued with upstream about which way is right.

Yep, the "NULL is zero" issue comes to mind.

> Sometimes the gcc headers will #include_next the system headers, but
> even then, they often do it at the beginning of the header so they can
> "fix" bugs in the system header. We (and apparently mingw ;) would
> prefer they #include_next at the end of the header, so we can fix bugs
> in the gcc headers. IIRC we used to revisit this problem with every
> gcc release, to see if there was a better way yet.

It's AFAIK the job of a platform maintainer for GCC, but I'm no longer
sure what exactly is the status of DJGPP support in GCC. Do they
consider us a dead platform? Debug info has been semi-broken for
years.

DJ Delorie

unread,
May 19, 2015, 1:29:26 PM5/19/15
to dj...@delorie.com

> > I think they're talking about the fact that gcc will internally add
> > -I's for its own headers dir, ahead of the system headers dir.
>
> Is that true even with -nostdinc?

The argument is that we can't rely on that, because the users won't be
using it.

The answer, however, is no. With --nostdinc, neither gcc's nor (I
assume, since I'm testing on Linux) djgpp's implicit includes are
included in the search list.

> Yes, I agree. So if we no longer have a reason to include GCC's
> headers while building the library, we should remove that inclusion
> from makefile.inc, I think.

Exception: if the "reason" is "the headers are broken", then we should
instead fix the headers. Otherwise, users will not get the same
headers as libc, and will/may still see the broken behavior.

> It's AFAIK the job of a platform maintainer for GCC,

The #include_next's are typically available for all platforms, unless
an exception is made. That complicates things upstream.

> but I'm no longer sure what exactly is the status of DJGPP support
> in GCC. Do they consider us a dead platform? Debug info has been
> semi-broken for years.

We (Andris :) maintain our own port with some djgpp-specific changes
(like codegen) pushed upstream and others (like dos-isms) not.

What's wrong with the debug info?

Eli Zaretskii (eliz@gnu.org)

unread,
May 19, 2015, 2:20:47 PM5/19/15
to DJ Delorie, dj...@delorie.com
> Date: Tue, 19 May 2015 13:29:18 -0400
> From: DJ Delorie <d...@delorie.com>
>
> > Yes, I agree. So if we no longer have a reason to include GCC's
> > headers while building the library, we should remove that inclusion
> > from makefile.inc, I think.
>
> Exception: if the "reason" is "the headers are broken", then we should
> instead fix the headers. Otherwise, users will not get the same
> headers as libc, and will/may still see the broken behavior.

Right.

> What's wrong with the debug info?

I don't really know, I never upgraded beyond GCC 3.4 and GDB 6.8,
because these two can still be used to debug executables with COFF
debug info. (I need COFF for Emacs.)

Juan probably knows much more, as he built every version of GDB until
now, and it's from him that I know that COFF debugging is unusable
with latest versions of GCC and GDB.

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 19, 2015, 4:04:21 PM5/19/15
to dj...@delorie.com
On 5/4/15, Andris Pavenis (andris....@iki.fi)
<djgpp-a...@delorie.com> wrote:
> This is announcement of DJGPP 2.05 beta 1
>
> It has numerous changes since previous DJGPP 2.04 beta 1 release in 2003.
> (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-announce/2003/12/06/22:18:05)
> Unfortunately DJGPP v2.04 was never released and old beta version slowly
> became almost unusable together with other newer DJGPP packages.
>
> More information about changes in DJGPP 2.05 beta 1 is available at
>
> http://www.delorie.com/djgpp/doc/kb/
>
> both in sections about changes in 2.04 and 2.05. The same information is
> also
> available in file info/kb.inf in djdev205.zip
>
> It needs a lot of testing. Please test it if you have time and/or are
> interested in any of the above features. Any level of testing would be
> appreciated.

zoneinfo fails build using a 2.03-based toolchain:

i586-pc-msdosdjgpp-gcc -pipe
-DTZDIR=\"/dev/env/DJDIR~c:/djgpp~/zoneinfo\" -o zic.exe
-DHAVE_ADJTIME=0 -DHAVE_LONG_DOUBLE=1 -DHAVE_SETTIMEOFDAY=1
-DHAVE_STRERROR=1 -DHAVE_SYMLINK=0 -DHAVE_STDINT_H=1 -DSTD_INSPIRED
-DLOCALE_HOME=\"/dev/env/DJDIR~c:/djgpp~/share/locale\" -Dlint -g2
-fno-common -fstrict-aliasing -Wall -Wextra -Wbad-function-cast
-Wcast-align -Wcast-qual -Wformat=2 -Winit-self -Wmissing-declarations
-Wmissing-noreturn -Wmissing-prototypes -Wnested-externs
-Wno-format-nonliteral -Wno-sign-compare -Wno-unused-parameter
-Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings
-Wconversion -Wtraditional -O2 zic.o localtime.o asctime.o scheck.o
ialloc.o
/usr/local/cross-dj203/lib/gcc/i586-pc-msdosdjgpp/3.4.6/../../../../i586-pc-msdosdjgpp/lib/libc.a(ctime.o):ctime.c:(.text+0x11f0):
multiple definition of `_tzsetwall'
localtime.o:/home/ozzie/dj5/zoneinfo/src/localtime.c:1218: first defined here
collect2: ld returned 1 exit status
make[1]: *** [zic.exe] Error 1
make: [subs] Error 2 (ignored)

That's because tzsetwall is not stub'ed in 2.03.

Besides, djgpp versions of zoneinfo programs (date.exe, zic.exe,
zdump.exe) are built against toolchain-provided djgpp headers and
linked against the toolchain-provided djgpp libs, which doesn't
sound right: we should use the same methods building the programs
from src/utils/, I can do that if this is aggreed upon.

--
O.S.

DJ Delorie

unread,
May 19, 2015, 4:42:11 PM5/19/15
to dj...@delorie.com

Beware, if parts of the tzinfo package are included in libc.a, we'd
need to keep doing it the way it's currently done.

Ozkan Sezer (sezeroz@gmail.com)

unread,
May 19, 2015, 4:59:04 PM5/19/15
to dj...@delorie.com
On 5/19/15, DJ Delorie <d...@delorie.com> wrote:
>
> Beware, if parts of the tzinfo package are included in libc.a, we'd
> need to keep doing it the way it's currently done.
>

tzsetwall() is part of libc.a:ctime.c but it is stubb'ed, therefore no
problems occur if zoneinfo is compiled using a 2.05-based toolchain.

As its build system currently is, the only way to make sure that it is
built+linked against current djgp is (i) build djgpp itself, (ii) update
your toolchain from that build, (iii) and rebuild djgpp and take tzinfo
stuff from that second build.

Rod Pemberton

unread,
May 19, 2015, 5:58:25 PM5/19/15
to
On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <d...@delorie.com> wrote:

>> D.J.
>
> If you've been around all this time, why don't you spell
> my name correctly yet?

I spelled it correctly. You capitalized both letters which
in English indicates it's an abbreviation of a first and
middle name. If it's not intended to be understood as
initials, then the second letter should be lowercased,
as in "Dj" like foreign names such as "Ng".

> "I'm insulted, and assume you're doing it on purpose
> just to annoy me[*]."
>
> [*] I'm not insulted, I assume you're innocently mistaken,
> just using it as an example of how people can mis-read
> others' posts.

Well, I should be insulted that you'd correct me for what
constitutes a spelling mistake on your part. Although,
it's your name so you can claim it's spelled any way you
want. You just don't have the right to correct others
when you chose to fail to follow English spelling rules.

Rod Pemberton

unread,
May 19, 2015, 6:13:14 PM5/19/15
to
On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <d...@delorie.com> wrote:

> Remember, Eli's native language is *not* English, despite how well he
> speaks it.

Well, then, he should chose to write in really bad English ...
No one would probably ever get mad at him again.

Hans-Bernhard Bröker

unread,
May 19, 2015, 6:19:39 PM5/19/15
to
Am 19.05.2015 um 23:58 schrieb Rod Pemberton:
> On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <d...@delorie.com> wrote:
>
>>> D.J.
>>
>> If you've been around all this time, why don't you spell
>> my name correctly yet?
>
> I spelled it correctly.

You're really quite full of it today, aren't you?

DJ Delorie

unread,
May 19, 2015, 6:34:42 PM5/19/15
to dj...@delorie.com

> I spelled it correctly. You capitalized both letters which
> in English indicates it's an abbreviation of a first and
> middle name. If it's not intended to be understood as
> initials, then the second letter should be lowercased,
> as in "Dj" like foreign names such as "Ng".

I find it amusing that you think you can tell me what my own name is.
It's my name, it's legal, and it's DJ - anything else is not my name.

(also... yes, I have the legal documents to prove it, and no, you may
not see them)

Rod Pemberton

unread,
May 19, 2015, 6:58:48 PM5/19/15
to
I don't know why you'd say that. I did spell it correctly.
Only the first letter of a name is capitalized in English.

A common example in English is Billy Joe as in Billy Joe Smith
as BJ Smith or B.J. Smith. E.g., if his name had been David
James Delorie, he would use DJ Delorie or D.J. Delorie.

English has a rule. "DJ" means "D.J." and not "Dj".

As long as "DJ" insists on violating English rules by using
"DJ" instead of "Dj" he is going to have people who understand
his name to be "D.J." End of story.

Rod Pemberton

unread,
May 19, 2015, 7:01:52 PM5/19/15
to
On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <d...@delorie.com> wrote:

>> rudely
>
> So you see it. I don't.

This is going to sound rude, but you don't "see"
rudeness. Well, I doubt that anyone "sees" rudeness ...

You stated you "can't even tell when my brother is
joking in an email, and I've known him all his life".

If you can't detect humor, how are you able to detect
rudeness? I think that's a fair question. Don't you?
If you can't detect rudeness, do you have the right
to make comments about it? I would say you don't.

Rod Pemberton

unread,
May 19, 2015, 7:07:00 PM5/19/15
to
You still don't have the right to correct others when you chose to
fail to follow English spelling rules. If "DJ" is your legal
first name, both capitals, then you should be well aware that it
doesn't follow conventional capitalization rules for English. You've
most likely been aware of this for your entire life. As such, your
just being a piece of shit by claiming that I misspelled your name.

Louis Santillan (lpsantil@gmail.com)

unread,
May 19, 2015, 7:24:31 PM5/19/15
to dj...@delorie.com
On Tue, May 19, 2015 at 2:58 PM, Rod Pemberton <fo...@lllljunkqwer.cpm> wrote:
> On Tue, 19 May 2015 13:05:07 -0400, DJ Delorie <d...@delorie.com> wrote:
>
>>> D.J.
>>
>>
>> If you've been around all this time, why don't you spell
>> my name correctly yet?
>
>
> I spelled it correctly. You capitalized both letters which
> in English indicates it's an abbreviation of a first and
> middle name. If it's not intended to be understood as
> initials, then the second letter should be lowercased,
> as in "Dj" like foreign names such as "Ng".
>
>> "I'm insulted, and assume you're doing it on purpose
>> just to annoy me[*]."
>>
>> [*] I'm not insulted, I assume you're innocently mistaken,
>> just using it as an example of how people can mis-read
>> others' posts.
>
>
> Well, I should be insulted that you'd correct me for what
> constitutes a spelling mistake on your part. Although,
> it's your name so you can claim it's spelled any way you
> want. You just don't have the right to correct others
> when you chose to fail to follow English spelling rules.

Please see [0][1][2].

[0] http://en.wikipedia.org/wiki/DJ_Delorie
[1] http://www.delorie.com/users/dj/
[2] http://www.delorie.com/users/dj/resume/

Louis Santillan (lpsantil@gmail.com)

unread,
May 19, 2015, 7:30:12 PM5/19/15
to dj...@delorie.com
See [0]. DJ is not an initialism, AFAIK. As such, D.J. is not
correct. Dj is not correct because his parents did not spell his name
that way in naming him. It's not hard to understand [1]. And once
you come across his situation, you'll find his parents did a great job
in giving him a unique and memorable name [2].

[0] http://www.englishgrammar.org/common-grammar-exceptions/
[1] https://xkcd.com/327/
[2] http://en.wikipedia.org/wiki/A_Boy_Named_Sue

DJ Delorie

unread,
May 19, 2015, 7:53:00 PM5/19/15
to dj...@delorie.com

> >> rudely
> >
> > So you see it. I don't.
>
> This is going to sound rude, but you don't "see"
> rudeness. Well, I doubt that anyone "sees" rudeness ...

Just for the sake of completeness, the expression I abbreviated is
"You see it that way, I don't see it that way." I'm merely noting
that point of view is important in interpreting some things.

> You stated you "can't even tell when my brother is
> joking in an email, and I've known him all his life".
>
> If you can't detect humor,

No, his humor just doesn't translate to email. He thinks he's funny,
nobody else does. Is it still humor? He thinks so, I don't.

> how are you able to detect rudeness? I think that's a fair
> question. Don't you?

It's a fair question. The answer is "Rudeness is what I think
rudeness is". It's a personal opinion. Mine is not always the same
as yours.

> If you can't detect rudeness, do you have the right
> to make comments about it? I would say you don't.

There are no "rights" here, though.

DJ Delorie

unread,
May 19, 2015, 7:57:58 PM5/19/15
to dj...@delorie.com

> I don't know why you'd say that. I did spell it correctly.

And the one person on the planet who's guaranteed to know better than
you, disagrees.

It's a name, not a word. The rules of English (or any language) are
irrelevent.

Eli Zaretskii (eliz@gnu.org)

unread,
May 19, 2015, 10:40:01 PM5/19/15
to dj...@delorie.com
> Date: Tue, 19 May 2015 23:04:07 +0300
> From: "Ozkan Sezer (sez...@gmail.com)" <dj...@delorie.com>
>
> Besides, djgpp versions of zoneinfo programs (date.exe, zic.exe,
> zdump.exe) are built against toolchain-provided djgpp headers and
> linked against the toolchain-provided djgpp libs, which doesn't
> sound right: we should use the same methods building the programs
> from src/utils/, I can do that if this is aggreed upon.

Sounds right to me.

Rod Pemberton

unread,
May 20, 2015, 7:27:33 AM5/20/15
to
On Tue, 19 May 2015 19:30:03 -0400, Louis Santillan (lpsa...@gmail.com)
<dj...@delorie.com> wrote:

> See [0]. DJ is not an initialism, AFAIK.

That's not the point.

> As such, D.J. is not correct.

No, "DJ" is not correct according to English rules. This was
stated previously. Did you even read the thread?

As such, he has no right to hold others accountable to it
when they're unaware his name doesn't follow English rules.
That's the point. That's what he was attempting to do.
That's wrong. He blamed me for the faults with his name.

> Dj is not correct because his parents did not spell his name
> that way in naming him.

The point was that if he doesn't want people to think his name
is abbreviated first and second initial, then he shouldn't
capitalize both. That's not hard to understand. This was
also already stated previously. Did you even read the thread?

If you read the thread, please stop responding as if you hadn't.

Rod Pemberton

unread,
May 20, 2015, 7:30:36 AM5/20/15
to
On Tue, 19 May 2015 19:57:52 -0400, DJ Delorie <d...@delorie.com> wrote:

>> I don't know why you'd say that. I did spell it correctly.
>
> And the one person on the planet who's guaranteed to know better
> than you, disagrees.

Wrong. I spelled it correctly according to English rules. The fact
that you or your parents violated norms isn't my problem. It's yours
and you have a simple solution which could prevent that from every
occuring again. Yet, you're attempting to hold me accountable for
for you or your parents mistake or aberrant behavior. That's wrong.
You have no right to do that.

> It's a name, not a word.

True. And, English has rules for capitalizing and abbreviating them.

> The rules of English (or any language) are irrelevent.

No, they aren't. You can't legitimately expect others to know
or respect the aberrant capitalization of your name.

Rod Pemberton

unread,
May 20, 2015, 7:40:22 AM5/20/15
to
On Tue, 19 May 2015 19:52:51 -0400, DJ Delorie <d...@delorie.com> wrote:

>> >> rudely
>> >
>> > So you see it. I don't.
>>
>> This is going to sound rude, but you don't "see"
>> rudeness. Well, I doubt that anyone "sees" rudeness ...
>
> Just for the sake of completeness, the expression I abbreviated is
> "You see it that way, I don't see it that way." I'm merely noting
> that point of view is important in interpreting some things.
>
>> You stated you "can't even tell when my brother is
>> joking in an email, and I've known him all his life".
>>
>> If you can't detect humor,
>
> No, his humor just doesn't translate to email. He thinks he's funny,
> nobody else does. Is it still humor? He thinks so, I don't.

How is that any different from my reply to Eli? He thinks he's
helping but the way he responds he only makes others angry ...
I explained this in depth and politely. This is documented, or
rather, archived. Yet, you took issue with me pointing that out
to him, but you have no issue with pointing out basically the same
thing of your brother.

"Pot calling the kettle black ..."

>> how are you able to detect rudeness? I think that's a fair
>> question. Don't you?
>
> It's a fair question. The answer is "Rudeness is what I think
> rudeness is". It's a personal opinion. Mine is not always the
> same as yours.

If everything of fact and truth is just personal opinion to you,
then what gives you the right to belittle and disrupt my serious
reply to Eli? It's my personal opinion according to your
perspective and has every right to stand as is because "mine
is not always the same as yours." Doesn't it? That's the only
logical outcome given what you've stated.

DJ Delorie

unread,
May 20, 2015, 1:17:09 PM5/20/15
to dj...@delorie.com

> You can't legitimately expect others to know or respect the aberrant
> capitalization of your name.

Sure I can. It's on every email I've sent out to the djgpp list:

> From: DJ Delorie <d...@delorie.com>

All you had to do is copy what you saw, but you chose to change it.

DJ Delorie

unread,
May 20, 2015, 1:18:27 PM5/20/15