ANNOUNCE: DJGPP 2.05 beta 1

[Andris Pavenis (andris.pavenis@iki.fi)]

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

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]

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

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

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]

> (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)]

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

[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)]

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

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

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

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

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

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

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

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]

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

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]

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

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

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

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

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

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

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

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

On 5/18/15, Eli Zaretskii (el...@gnu.org) <dj...@delorie.com> wrote:

Joke, right?

[Eli Zaretskii (eliz@gnu.org)]

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

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

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

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

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

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]

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

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

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

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

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

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

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

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]

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

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]

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]

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]

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]

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

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]

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]

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

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

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]

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

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

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

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]

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]

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]

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

> How is that any different from my reply to Eli?

The difference is that I kept my opinion to myself, whereas you chose
to dictate it to others as if it were fact.

[Juan Manuel Guerrero (juan.guerrero@gmx.de)]

Today I have ported and compiled gdb-7.9.1.tar.gz. The COFF/dwarf support is
as broken as with gdb-7.8. and later versions. The last gdb version with working
djgpp support is gdb-7.7.1.tar.gz. I do not think that they have intentionally
removed or brocken djgpp support. But an inspection of the changelog file shows
that they have modified go32-nat.c but not only this one. This change seems to be
part of a major modification or rewrite of that particular code segments.

From Changelog-2014:

2014-03-07 Pedro Alves <pal...@redhat.com>

* go32-nat.c: Include inf-child.h.
(go32_ops): Delete global.
(go32_close, go32_detach, go32_prepare_to_store, go32_can_run):
Delete methods.
(go32_create_inferior): Push the passed in target pointer instead
of referencing go32_ops.
(init_go32_ops): Delete function. Moved parts to _initialize_go32_nat.
(go32_target): New function, based on init_go32_ops, but inherit
inf_child_target.
(_initialize_go32_nat): Use go32_target. Move parts of
init_go32_ops here.

I have inspected those changes and they seem to have been well done. So it is
not clear what has been brocken.
Unfortunately I have absolute no knowledge about DWARF and especially I do not
understand how the djgpp support of gdb works. So I cannot debug nor figure out
this issue.

Unfortunately I have no other COFF/dwarf2 system to check if it is brocken too.
Of course I exclude PE-COFF. If this target would have been brocken then
a lot of complains would have been sended to the gdb mailing list. And of course
PE-COFF is not really the same than COFF.

I have compiled this gdb port using djdev204, gcc492 and bnu224br2. I have
intentionally used djdev204 to avoid the inference of any bugs that may be
present in djdev205 and bnu225b (because compiled with djdev205). The pain
is not worth to try to compile this gdb port using djdev203. It would also
not work as the port of gdb 7.8 has already not worked.

I have compiled a simple hello-world program using the same configuration than
the one used to compile the gdb port. It fails the same way it used to fail
with gdb 7.8. Nothing changed compared against that version.
Please note that the same program can be flawlessly debugged using the gdb 7.7.1
port! So this is certainly something brocken or in gdb or in bfd but not in our
libraries and ports.

For more information pleace read the thread:
<http://www.delorie.com/archives/browse.cgi?p=djgpp/2014/08/08/14:46:57>


Regards,
Juan M. Guerrero



C:\tmp\5>a
qwertz
C:\tmp\5>gdb a.exe
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i786-pc-msdosdjgpp --target=djgpp".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.exe...done.
(gdb) b main
Breakpoint 1 at 0x1ed8: file a.c, line 4.
(gdb) r
Starting program: c:/tmp/5/a.exe
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1ed8

(gdb) s
Single stepping until exit from function start,
which has no line number information.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1ed8
Cannot insert breakpoint -2.
Cannot access memory at address 0x57b0

(gdb)

[Andris Pavenis (andris.pavenis@iki.fi)]

This change is most likely only a result of other changes. So if we do not know these other changes
it would be very difficult to see whether that go32-nat.c change is actually OK or some detail is
accidentally left out.

Perhaps it is necessary to look for in GDB GIT repository to see which change actually broke DJGPP
support between creating gdb_7_7_branch and gdb-7.8 release. 'git bisect' could perhaps help. Then
it could be more clear what went wrong

Andris

[Eli Zaretskii (eliz@gnu.org)]

> Date: Thu, 21 May 2015 07:25:20 +0300
> From: "Andris Pavenis (andris....@iki.fi)" <dj...@delorie.com>

>
> This change is most likely only a result of other changes. So if we do not know these other changes
> it would be very difficult to see whether that go32-nat.c change is actually OK or some detail is
> accidentally left out.

Juan quoted a discussion from a year ago, which ended with this
conclusion:

> >> (gdb) r
> >> Starting program: h:/l/bins/bin/a.exe

> >> Warning:
> >> Cannot insert breakpoint 1.

> >> Cannot access memory at address 0x1e04
> > This means inserting a breakpoint at 0x1e04 returned EIO. I suggest
> > to take a good look at the code that's involved in this. I see that
> > in GDB-7.7.1, we had these 2 lines in go32-nat.c:
> >
> > go32_ops.to_insert_breakpoint = memory_insert_breakpoint;
> > go32_ops.to_remove_breakpoint = memory_remove_breakpoint;
> >
> > but these lines are no longer there, and instead the go32 target
> > inherits from inf_child_target. Perhaps that's the cause of the
> > problem.
>
> Thank you for the pointer. The change from the old way to handle the
> native support to the new way of initializing struct target_ops inf_child_ops
> by inf_child_target and go32_target seems to be the source of the difficulties.
> At least go32_ops.to_insert_breakpoint and go32_ops.to_remove_breakpoint are
> not set to the corresponding equivalent new variables for DJGPP.

Can we pick up where this was left off?

FWIW, I don't understand what Juan wrote back then: go32_ops no longer
exists in the current sources. Instead, the initialization calls
go32_target, which does this:

static struct target_ops *
go32_target (void)
{
struct target_ops *t = inf_child_target ();

In inf_child_target, I see that to_insert_breakpoint and
to_remove_breakpoint are correctly assigned:

struct target_ops *
inf_child_target (void)
{
struct target_ops *t = XCNEW (struct target_ops);

[...]
t->to_insert_breakpoint = memory_insert_breakpoint;
t->to_remove_breakpoint = memory_remove_breakpoint;

Back in the go32-nat initialization function, we have this call, after
all the members of target_ops were initialized:

add_target (t);

where before GDB 7.8 it did this instead:

add_target (&go32_ops);

This all looks OK to me, and I just stepped through the corresponding
code for the MinGW native target and saw that it does the same (and
certainly works, as I use it every day).

So what and how goes wrong in the DJGPP build of GDB? Can someone
with enough free time step through the go32 initialization, and see
what's wrong there?

TIA

[Ozkan Sezer (sezeroz@gmail.com)]

Pushed the following for src/libm/math/w[f]_cabs.c:

use __complex__ instead of _Complex so that it compiles with gcc2 too

Index: src/libm/math/w_cabs.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libm/math/w_cabs.c,v
retrieving revision 1.4
diff -u -r1.4 w_cabs.c
--- src/libm/math/w_cabs.c 20 Aug 2011 12:41:02 -0000 1.4
+++ src/libm/math/w_cabs.c 23 May 2015 00:12:27 -0000
@@ -11,11 +11,11 @@
#include "fdlibm.h"

#ifdef __STDC__
-double cabs(_Complex double);
-double cabs(_Complex double z)
+double cabs(__complex__ double);
+double cabs(__complex__ double z)
#else
double cabs(z)
- _Complex double z;
+ __complex__ double z;
#endif
{
return hypot(__real__ z, __imag__ z);
Index: src/libm/math/wf_cabs.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libm/math/wf_cabs.c,v
retrieving revision 1.4
diff -u -r1.4 wf_cabs.c
--- src/libm/math/wf_cabs.c 20 Aug 2011 12:41:02 -0000 1.4
+++ src/libm/math/wf_cabs.c 23 May 2015 00:12:27 -0000
@@ -11,11 +11,11 @@
#include "fdlibm.h"

#ifdef __STDC__
-float cabsf(_Complex float);
-float cabsf(_Complex float z)
+float cabsf(__complex__ float);
+float cabsf(__complex__ float z)
#else
float cabsf(z)
- _Complex float z;
+ __complex__ float z;
#endif
{
return hypotf(__real__ z, __imag__ z);

[Ozkan Sezer (sezeroz@gmail.com)]

Applied the following to dxe3.gen.c so that it compiles with gcc2:

* dxe3gen.c: change the variable length array from [] to [0] so that
it compiles using gcc2

Index: src/dxe/dxe3gen.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/dxe/dxe3gen.c,v
retrieving revision 1.19
diff -u -r1.19 dxe3gen.c
--- src/dxe/dxe3gen.c 17 May 2015 12:55:18 -0000 1.19
+++ src/dxe/dxe3gen.c 22 May 2015 22:08:42 -0000
@@ -168,8 +168,9 @@
#ifndef DXE_LD
/* Cross compile ld name/location */
#define DXE_LD "ld"
-#else
-/* Linux violates POSIX.1 and defines this, but it shouldn't. We fix it. */
+#endif
+#ifdef _POSIX_SOURCE
+/* Linux violates POSIX.1 and defines this, but it shouldn't.. */
#undef _POSIX_SOURCE
#endif

@@ -684,7 +685,7 @@
uword length;
sword CIE_id;
ubyte version;
- unsigned char augmentation[];
+ unsigned char augmentation[0];
} __attribute__ ((packed, aligned (__alignof__ (void *))));

[Ozkan Sezer (sezeroz@gmail.com)]

Applied the following to sys/dxe.h:

* sys/dxe.h: change intptr_t usage with size_t so we can compile using
2.03-based toolchains

Index: include/sys/dxe.h
===================================================================
RCS file: /cvs/djgpp/djgpp/include/sys/dxe.h,v
retrieving revision 1.9
diff -u -r1.9 dxe.h
--- include/sys/dxe.h 17 May 2015 12:55:18 -0000 1.9
+++ include/sys/dxe.h 22 May 2015 22:08:41 -0000
@@ -10,7 +10,7 @@
#ifndef __dj_include_dxe_h_
#define __dj_include_dxe_h_

-#include <stdint.h> /* for intptr_t */
+#include <stddef.h> /* for size_t */

/* the following are needed when cross compiling hostbin exes */
#ifndef _DJ_DEFINED_NATIVE_TYPES
@@ -217,7 +217,7 @@
dlregsym ((void *)&__alias__##name); \
} \
static __attribute_used dxe_symbol_table name [] = {
-#define DXE_EXPORT(symbol) { "_" #symbol, (void *)(intptr_t)&symbol },
+#define DXE_EXPORT(symbol) { "_" #symbol, (void *)(size_t)&symbol },
#define DXE_EXPORT_END { 0, 0 }};

/*

[Ozkan Sezer (sezeroz@gmail.com)]

Applied the following to doprnt.c:

doprnt.c: removed the CHARINT case from the ARG macro.
(char basetype) seems wrong and the case is handled
with the generic case already.

Index: src/libc/ansi/stdio/doprnt.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/doprnt.c,v
retrieving revision 1.36
diff -u -r1.36 doprnt.c
--- src/libc/ansi/stdio/doprnt.c 10 Jan 2014 18:21:56 -0000 1.36
+++ src/libc/ansi/stdio/doprnt.c 23 May 2015 00:21:23 -0000
@@ -48,7 +48,6 @@
flags & LONGDBL ? va_arg(argp, long long basetype) : \
flags & LONGINT ? va_arg(argp, long basetype) : \
flags & SHORTINT ? (short basetype)va_arg(argp, int) : \
- flags & CHARINT ? (char basetype)va_arg(argp, int) : \
(basetype)va_arg(argp, int)

#define CONVERT(type, value, base, string, case) \

[Ozkan Sezer (sezeroz@gmail.com)]

Applied the following to doprnt.c:

* doprnt.c: avoid unused warnings from gcc2

Index: doprnt.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/doprnt.c,v
retrieving revision 1.37
diff -u -r1.37 doprnt.c
--- doprnt.c 23 May 2015 08:35:29 -0000 1.37
+++ doprnt.c 23 May 2015 08:37:04 -0000
@@ -1374,7 +1374,7 @@
return argp;
if (prec_index == list_index)
{
- va_arg(argp, int); /* discard */
+ _ulonglong = va_arg(argp, int); /* discard */
list_index++;
}
goto rflag;
@@ -1387,7 +1387,7 @@
return argp;
if (prec_index == list_index)
{
- va_arg(argp, int); /* discard */
+ _ulonglong = va_arg(argp, int); /* discard */
list_index++;
}
}
@@ -1422,7 +1422,7 @@
return argp;
if (arg_index == list_index)
{
- va_arg(argp, int); /* discard */
+ _ulonglong = va_arg(argp, int); /* discard */
list_index++;
}
break;
@@ -1445,9 +1445,9 @@
if (arg_index == list_index)
{
if (flags & LONGDBL)
- va_arg(argp, long double); /* discard */
+ _ulonglong = va_arg(argp, long double); /* discard */
else
- va_arg(argp, double); /* discard */
+ _ulonglong = va_arg(argp, double); /* discard */
list_index++;
}
break;
@@ -1468,7 +1468,7 @@
return argp;
if (arg_index == list_index)
{
- va_arg(argp, void *); /* discard */
+ _ulonglong = (size_t) va_arg(argp, void *); /* discard */
list_index++;
}
break;

[Ozkan Sezer (sezeroz@gmail.com)]

Applied the following in order to avoid stdbool.h usage:
As I stated earlier in this thread our stdbool.h is broken
(and gcc provides its stdbool.h) and it leads to failures
such as:

cc1.exe: warnings being treated as errors
doscan.c:38: warning: type defaults to `int' in declaration of `_Bool'
doscan.c:38: parse error before `allocate_char_buffer'
doscan.c:38: warning: function declaration isn't a prototype
doscan.c:41: warning: type defaults to `int' in declaration of `_Bool'
doscan.c:41: parse error before `allocate_char_buffer'
doscan.c:41: warning: function declaration isn't a prototype
doscan.c: In function `_doscan_low':
doscan.c:71: `_Bool' undeclared (first use in this function)

---

* doprnt.c, doscan.c: locally define bool/false/true and remove the
stdbool.h usage.

* libc/ansi/time/strftime.c: revert parts of r1.8 and simply use 0
and 1 instead of true and false again.

* djtar/unbzip2.c: revert parts of r1.4 and go back to the original
TRUE and FALSE usage.

* tests/libc/c99/math/t-ismac.c: locally define bool/false/true and
remove stdbool.h usage.

Index: src/libc/ansi/stdio/doprnt.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/doprnt.c,v
retrieving revision 1.36
diff -u -p -r1.36 doprnt.c

--- src/libc/ansi/stdio/doprnt.c 10 Jan 2014 18:21:56 -0000 1.36

+++ src/libc/ansi/stdio/doprnt.c 13 May 2015 08:02:10 -0000
@@ -21,12 +21,15 @@
#include <string.h>
#include <math.h>
#include <limits.h>
-#include <stdbool.h>
#include <libc/file.h>
#include <libc/local.h>
#include <libc/ieee.h>
#include <sys/cdefs.h>

+typedef enum {
+ false = 0, true = 1
+} bool;
+
static char decimal_point;
static char thousands_sep;
static char *grouping;
Index: src/libc/ansi/stdio/doscan.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/doscan.c,v
retrieving revision 1.24
diff -u -p -r1.24 doscan.c
--- src/libc/ansi/stdio/doscan.c 2 May 2015 07:32:04 -0000 1.24
+++ src/libc/ansi/stdio/doscan.c 13 May 2015 08:02:10 -0000
@@ -12,12 +12,15 @@
#include <stdlib.h>
#include <ctype.h>
#include <locale.h>
-#include <stdbool.h>
#include <stddef.h>
#include <errno.h>
#include <libc/file.h>
#include <libc/local.h>

+typedef enum {
+ false = 0, true = 1
+} bool;
+
#define SPC 01
#define STP 02


Index: src/libc/ansi/time/strftime.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/time/strftime.c,v
retrieving revision 1.10
diff -u -p -r1.10 strftime.c
--- src/libc/ansi/time/strftime.c 2 May 2015 07:32:14 -0000 1.10
+++ src/libc/ansi/time/strftime.c 13 May 2015 08:03:02 -0000
@@ -9,7 +9,6 @@
#include <string.h>
#include <time.h>
#include <ctype.h>
-#include <stdbool.h>


#define THURSDAY 4
@@ -164,21 +163,21 @@ _fmt(const char *format, const struct tm
{
if (*format == '%')
{
- int flag_seen, pad = '0', space=' ', swap_case = false;
+ int flag_seen, pad = '0', space=' ', swap_case = 0;

/* Parse flags. */
do {
- flag_seen = false;
+ flag_seen = 0;
if (format[1] == '_')
- flag_seen = true, pad = space = ' ', format++;
+ flag_seen = 1, pad = space = ' ', format++;
if (format[1] == '-')
- flag_seen = true, pad = space = 0, format++;
+ flag_seen = 1, pad = space = 0, format++;
if (format[1] == '0')
- flag_seen = true, pad = space = '0', format++;
+ flag_seen = 1, pad = space = '0', format++;
if (format[1] == '^')
- flag_seen = true, upcase = true, format++;
+ flag_seen = 1, upcase = 1, format++;
if (format[1] == '#')
- flag_seen = true, swap_case = true, format++;
+ flag_seen = 1, swap_case = 1, format++;
} while (flag_seen);

/* Parse modifiers. */
@@ -192,7 +191,7 @@ _fmt(const char *format, const struct tm
break;
case 'A':
if (swap_case)
- upcase = true;
+ upcase = 1;
if (t->tm_wday < 0 || t->tm_wday > 6)
return 0;
if (!_add(Afmt[t->tm_wday], upcase))
@@ -200,7 +199,7 @@ _fmt(const char *format, const struct tm
continue;
case 'a':
if (swap_case)
- upcase = true;
+ upcase = 1;
if (t->tm_wday < 0 || t->tm_wday > 6)
return 0;
if (!_add(afmt[t->tm_wday], upcase))
@@ -208,7 +207,7 @@ _fmt(const char *format, const struct tm
continue;
case 'B':
if (swap_case)
- upcase = true;
+ upcase = 1;
if (t->tm_mon < 0 || t->tm_mon > 11)
return 0;
if (!_add(Bfmt[t->tm_mon], upcase))
@@ -217,7 +216,7 @@ _fmt(const char *format, const struct tm
case 'b':
case 'h':
if (swap_case)
- upcase = true;
+ upcase = 1;
if (t->tm_mon < 0 || t->tm_mon > 11)
return 0;
if (!_add(bfmt[t->tm_mon], upcase))
@@ -294,7 +293,7 @@ _fmt(const char *format, const struct tm
return 0;
continue;
case 'p':
- upcase = swap_case ? false : true;
+ upcase = swap_case ? 0 : 1;
if (!_add(t->tm_hour >= 12 ? "pm" : "am", upcase))
return 0;
continue;
@@ -381,7 +380,7 @@ _fmt(const char *format, const struct tm
strcpy(tm_zone, t->tm_zone);
if (swap_case)
{
- upcase = false;
+ upcase = 0;
strlwr(tm_zone);
}
if (!_add(tm_zone, upcase))
@@ -418,7 +417,7 @@ strftime(char *s, size_t maxsize, const
pt = s;
if ((gsize = maxsize) < 1)
return 0;
- if (_fmt(format, t, false))
+ if (_fmt(format, t, 0))
{
*pt = '\0';
return maxsize - gsize;

Index: src/utils/djtar/unbzip2.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/utils/djtar/unbzip2.c,v
retrieving revision 1.5
diff -u -p -r1.5 unbzip2.c
--- src/utils/djtar/unbzip2.c 9 Jan 2011 14:19:57 -0000 1.5
+++ src/utils/djtar/unbzip2.c 13 May 2015 08:03:28 -0000
@@ -2,17 +2,19 @@
/* Copyright (C) 2001 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2000 DJ Delorie, see COPYING.DJ for details */

-/*
+/*
* This file provides bzip2 support for DJTAR.
*/


#include <stdlib.h>
-#include <stdbool.h>
#include "oread.h"
#include "zread.h"
#include "unbzip2.h"

+#define FALSE 0
+#define TRUE 1
+
local int read_stream (void)
{
int bytes_in, bytes_read;
@@ -39,21 +41,21 @@ local int read_stream (void)
if ((bzip_status) == BZ_OK && nbytes == EOF && \
data->avail_in == 0 && data->avail_out > 0) \
goto error_handler; \
- } while (false)
+ } while (FALSE)

#define CHECK_IF_BZ_STREAM_END_IS_EOF(buf) \
do { \
if ((buf)[0] == 'B' && (buf)[1] == 'Z' && (buf)[2] == 'h') \
- EOF_reached = false; \
+ EOF_reached = FALSE; \
else \
- EOF_reached = true; \
- } while (false)
+ EOF_reached = TRUE; \
+ } while (FALSE)

int unbzip2 (void *f)
{
bz_stream* data = NULL;
int bzip_status;
- int EOF_reached = true;
+ int EOF_reached = TRUE;
int small = 0; /* Use fast decompressing algorithm. */
int verbosity = 0; /* No verbose output at all. */
int nbytes = 0;
@@ -79,7 +81,7 @@ int unbzip2 (void *f)
goto error_handler;

/* Decompress every stream (.bz2 file) contained in this file. */
- while (true)
+ while (TRUE)
{
/* Decompress the actual stream (.bz2 file) contained in this file. */
while (bzip_status == BZ_OK)

Index: tests/libc/c99/math/t-ismac.c
===================================================================
RCS file: /cvs/djgpp/djgpp/tests/libc/c99/math/t-ismac.c,v
retrieving revision 1.1
diff -u -p -r1.1 t-ismac.c
--- tests/libc/c99/math/t-ismac.c 23 Mar 2013 11:58:58 -0000 1.1
+++ tests/libc/c99/math/t-ismac.c 13 May 2015 08:04:50 -0000
@@ -1,10 +1,12 @@
#include "../../../../include/stdio.h"
#include "../../../../include/math.h"
#include "../../../../include/libc/ieee.h"
-#include <stdbool.h>

#define TEST_TYPE 0 /* Allowed 0 or 1 */

+typedef enum {
+ false = 0, true = 1
+} bool;

typedef union
{

[Ozkan Sezer (sezeroz@gmail.com)]

Using an unmodified 2.03-based toolchain/djgpp environment,
current cvs fails like the following:

./../../lib/libc.a(crt1.o)(.text+0x25d):crt1.c: undefined reference
to `_environ'
./../../lib/libc.a(crt1.o)(.text+0x2c4):crt1.c: undefined reference
to `_environ'
./../../lib/libc.a(crt1.o)(.text+0x2d0):crt1.c: undefined reference
to `_environ'
./../../lib/libc.a(crt1.o)(.text+0x2f7):crt1.c: undefined reference
to `_environ'
./../../lib/libc.a(crt1.o)(.text+0x516):crt1.c: undefined reference
to `_environ'
./../../lib/libc.a(spawnvp.o)(.text+0x11):spawnvp.c: more undefined
references to `_environ' follow
make.exe[3]: *** [../../../bin/symify.exe] Error 1

However, if I specify djgpp.djl on the make line, like:
make DJGPP_DJL=c:/v205/lib/djgpp.djl
.. then build happily succeeds.

Why are we using the toolchain-provided linker script instead
of source tree-provided one? If this was an oversight, I can
easily change this.

--
O.S.

[Eli Zaretskii (eliz@gnu.org)]

> Date: Sat, 23 May 2015 12:24:08 +0300

> From: "Ozkan Sezer (sez...@gmail.com)" <dj...@delorie.com>
>

> Using an unmodified 2.03-based toolchain/djgpp environment,
> current cvs fails like the following:
>

> ../../../lib/libc.a(crt1.o)(.text+0x25d):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(crt1.o)(.text+0x2c4):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(crt1.o)(.text+0x2d0):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(crt1.o)(.text+0x2f7):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(crt1.o)(.text+0x516):crt1.c: undefined reference
> to `_environ'
> ../../../lib/libc.a(spawnvp.o)(.text+0x11):spawnvp.c: more undefined

> references to `_environ' follow
> make.exe[3]: *** [../../../bin/symify.exe] Error 1
>
> However, if I specify djgpp.djl on the make line, like:
> make DJGPP_DJL=c:/v205/lib/djgpp.djl

> ... then build happily succeeds.

>
> Why are we using the toolchain-provided linker script instead
> of source tree-provided one? If this was an oversight, I can
> easily change this.

I'm guessing that no one envisioned the linker script will be ever
modified.

Using the script from the source tree is TRT, IMO.

Thanks.

[Ozkan Sezer (sezeroz@gmail.com)]

Applied the following to zoneinfo/src/private.h (and updated djdiffs afterwards)

private.h: add missing INT64_MAX, INT_FAST32_MAX, INT_FAST32_MAX,
and the corresponding *_MIN macros, in case one wants to compile
without -DHAVE_STDINT_H=1 (otherwise compilation fails.)

Index: private.h
===================================================================
RCS file: /cvs/djgpp/djgpp/zoneinfo/src/private.h,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- private.h 17 Aug 2013 21:04:16 -0000 1.7
+++ private.h 23 May 2015 12:32:51 -0000 1.8
@@ -155,11 +155,20 @@
#endif /* ! (defined LLONG_MAX || defined __LONG_LONG_MAX__) */
#endif /* !defined INT_FAST64_MAX */

+#ifndef INT64_MAX
+# define INT64_MAX INT_FAST64_MAX
+# define INT64_MIN INT_FAST64_MIN
+#endif
+
#ifndef INT_FAST32_MAX
# if INT_MAX >> 31 == 0
typedef long int_fast32_t;
+# define INT_FAST32_MAX LONG_MAX
+# define INT_FAST32_MIN LONG_MIN
# else
typedef int int_fast32_t;
+# define INT_FAST32_MAX INT_MAX
+# define INT_FAST32_MIN INT_MIN
# endif
#endif

[Ozkan Sezer (sezeroz@gmail.com)]

OK then, applied the following:

* src/makefile.inc: use source tree-provided djgpp.djl, instead of
toolchain-provided one. (and do not export DJGPP_DJL so that this
actually works.)

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 23 May 2015 11:01:32 -0000
@@ -131,12 +131,8 @@
endif

ifeq ($(DJGPP_DJL),)
-DJGPP_DJL := $(shell $(CROSS_GCC) $(GCC_OPT) -print-file-name=djgpp-x.djl)
-ifeq ($(DJGPP_DJL),djgpp-x.djl)
-DJGPP_DJL := $(shell $(CROSS_GCC) $(GCC_OPT) -print-file-name=djgpp.djl)
-endif
-DJGPP_DJL := $(subst \,/,$(DJGPP_DJL))
-export DJGPP_DJL
+DJGPP_DJL = $(LIB)/djgpp.djl
+#export DJGPP_DJL
endif

LINK = $(CROSS_LD) -s $(LDFLAGS) $(filter %.o,$^) $(filter-out
%.o,$^) -o $@ $(LIBGCCA) -T $(DJGPP_DJL)

--

[Ozkan Sezer (sezeroz@gmail.com)]

Updated patch for zoneinfo build system follows (also attached
as a patch file.) Bulid tested using 2.03 and 2.05 cross toolchains,
also successfully built under winxp using gcc-2.95 and djgpp-2.03
based environment. If no objections, I plan to apply this tomorrow.

* build tz binaries against source-tree, not against toolchain:
- zic: define as dos-zic.exe or host-zic.exe depending on cross
or native build.
- host-zic: place in $(TOPDIR)/hostbin like other utils.
- HOST_ZIC: new var for 'host-zic' for cross-builds.
- HOST_ZIC: do not build if cross-compiling, copy over target-
zic.exe to hostbin/ instead.
- LIBGCCA, DJGPP_DJL: copied defitinions from src/makefile.inc.
- CFLAGS: add -nostdinc -I$(TOPDIR)/include
- GCCFLAGS: (kept intact)
- zdump.exe, zic.exe, date.exe: change rules to link against
freshly built crt0.o and libc.a.
- date.exe: remove logwtmpl.a building, because it was linking
to locally built logwtmpl.a and logwtmp.o is simply an empty
object for dos-targeting builds.
- debug flags: made them to work old compilers too, and cleaned
and tidied a bit.

Index: zoneinfo/src/makefile
===================================================================
RCS file: /cvs/djgpp/djgpp/zoneinfo/src/makefile,v

retrieving revision 1.16
diff -u -r1.16 makefile

--- zoneinfo/src/makefile 26 Nov 2013 18:08:51 -0000 1.16
+++ zoneinfo/src/makefile 23 May 2015 12:55:50 -0000
@@ -87,6 +87,27 @@
CROSS_GCC_MAJOR := $(word 3, $(shell ../../src/misc.exe |
$(CROSS_GCC) -E -dD -x c - | egrep 'define\ *__GNUC__'))
CROSS_GCC_MINOR := $(word 3, $(shell ../../src/misc.exe |
$(CROSS_GCC) -E -dD -x c - | egrep 'define\ *__GNUC_MINOR__'))

+# very old gcc, e.g. gcc-2.95, fails the above, so we invent a default.
+ifeq ($(GCC_MAJOR),)
+GCC_MAJOR := 2
+GCC_MINOR := 7
+endif
+ifeq ($(CROSS_GCC_MAJOR),)
+CROSS_GCC_MAJOR := 2
+CROSS_GCC_MINOR := 7
+endif
+
+ifeq ($(LIBGCCA),)
+LIBGCCA := $(shell $(CROSS_GCC) $(GCC_OPT) -print-file-name=libgcc.a)
+LIBGCCA := $(subst \,/,$(LIBGCCA))
+export LIBGCCA
+endif
+
+ifeq ($(DJGPP_DJL),)
+DJGPP_DJL = $(TOPDIR)/lib/djgpp.djl
+#export DJGPP_DJL
+endif
+
# A replacement for (possibly missing) Unix programs:

UTIL= $(TOPDIR)/src/misc.exe
@@ -162,97 +183,48 @@
# -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines \
# -Wwrite-strings

+COMMON_DEBUG_FLAGS = -Dlint -g -fno-common -fstrict-aliasing \
+ -Wall -W -Wcast-align -Wcast-qual -Wpointer-arith \
+ -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes \
+ -Wnested-externs -Wshadow -Wwrite-strings
+
# Cross compiler debug flags.
-CROSS_GCC_DEBUG_FLAGS_FOR_ALL = -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
-
-ifeq ($(CROSS_GCC_MAJOR),3)
-ifeq ($(CROSS_GCC_MINOR),4)
-CROSS_GCC_DEBUG_FLAGS = $(CROSS_GCC_DEBUG_FLAGS_FOR_ALL) -Wconversion
-Wtraditional
+ifeq ($(filter 2,$(CROSS_GCC_MAJOR)),)
+# gcc >= 3.x
+CROSS_GCC3_DFLAGS = -Wbad-function-cast -Wno-sign-compare -Wno-unused-parameter
+ifeq ($(filter 3,$(CROSS_GCC_MAJOR)),)
+ifeq ($(filter 4,$(CROSS_GCC_MAJOR)),)
+# gcc >= 5.x
+CROSS_GCC4_DFLAGS = -Wno-type-limits
+else
+# gcc >= 4.x
+ifeq ($(filter 0 1 2,$(CROSS_GCC_MINOR)),)
+# gcc >= 4.3
+CROSS_GCC4_DFLAGS = -Wno-type-limits
+endif
endif
endif
-
-ifeq ($(CROSS_GCC_MAJOR),4)
- ifeq ($(CROSS_GCC_MINOR),0)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL =
- else
- ifeq ($(CROSS_GCC_MINOR),1)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL =
- else
- ifeq ($(CROSS_GCC_MINOR),2)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
- else
- ifeq ($(CROSS_GCC_MINOR),3)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-Wno-sign-conversion -Wno-type-limits
- else
- ifeq ($(CROSS_GCC_MINOR),4)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-Wno-sign-conversion -Wno-type-limits
- else
- ifeq ($(CROSS_GCC_MINOR),5)
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-Wno-sign-conversion -Wno-type-limits
- else
-# gcc 4.6 and later works.
-CROSS_GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
-Wno-sign-conversion -Wno-type-limits -Wsuggest-attribute=const
-Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines
- endif
- endif
- endif
- endif
- endif
-CROSS_GCC_DEBUG_FLAGS = $(CROSS_GCC_DEBUG_FLAGS_FOR_ALL)
$(CROSS_GCC_DEBUG_FLAGS_SPECIAL)
- endif
endif
+CROSS_GCC_DEBUG_FLAGS = $(COMMON_DEBUG_FLAGS) $(CROSS_GCC3_DFLAGS)
$(CROSS_GCC4_DFLAGS)

# Native compiler debug flags.
-GCC_DEBUG_FLAGS_FOR_ALL = -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
-
-ifeq ($(GCC_MAJOR),3)
-ifeq ($(GCC_MINOR),4)
-GCC_DEBUG_FLAGS = $(GCC_DEBUG_FLAGS_FOR_ALL) -Wconversion -Wtraditional
+ifeq ($(filter 2,$(GCC_MAJOR)),)
+# gcc >= 3.x
+GCC3_DEBUG_FLAGS = -Wbad-function-cast -Wno-sign-compare -Wno-unused-parameter
+ifeq ($(filter 3,$(GCC_MAJOR)),)
+ifeq ($(filter 4,$(GCC_MAJOR)),)
+# gcc >= 5.x
+GCC4_DEBUG_FLAGS = -Wno-type-limits
+else
+# gcc >= 4.x
+ifeq ($(filter 0 1 2,$(GCC_MINOR)),)
+# gcc >= 4.3
+GCC4_DEBUG_FLAGS = -Wno-type-limits
+endif
endif
endif
-
-ifeq ($(GCC_MAJOR),4)
- ifeq ($(GCC_MINOR),0)
-GCC_DEBUG_FLAGS_SPECIAL =
- else
- ifeq ($(GCC_MINOR),1)
-GCC_DEBUG_FLAGS_SPECIAL =
- else
- ifeq ($(GCC_MINOR),2)
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings
- else
- ifeq ($(GCC_MINOR),3)
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
-Wno-type-limits
- else
- ifeq ($(GCC_MINOR),4)
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
-Wno-type-limits
- else
- ifeq ($(GCC_MINOR),5)
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
-Wno-type-limits
- else
-# gcc 4.6 and later works.
-GCC_DEBUG_FLAGS_SPECIAL = -Woverlength-strings -Wno-sign-conversion
-Wno-type-limits -Wsuggest-attribute=const
-Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines
- endif
- endif
- endif
- endif
- endif
-GCC_DEBUG_FLAGS = $(GCC_DEBUG_FLAGS_FOR_ALL) $(GCC_DEBUG_FLAGS_SPECIAL)
- endif
endif
+GCC_DEBUG_FLAGS = $(COMMON_DEBUG_FLAGS) $(GCC3_DEBUG_FLAGS) $(GCC4_DEBUG_FLAGS)

#
# If you want to use System V compatibility code, add
@@ -349,7 +321,7 @@
-DHAVE_STRERROR=1 -DHAVE_SYMLINK=0 -DHAVE_STDINT_H=1\
-DSTD_INSPIRED \
-DLOCALE_HOME=\"/dev/env/DJDIR~c:/djgpp~/share/locale\" \
- $(CROSS_GCC_DEBUG_FLAGS) -O2
+ $(CROSS_GCC_DEBUG_FLAGS) -O2 -nostdinc -I$(TOPDIR)/include

# Flags for native compiler
GCCFLAGS= -DHAVE_ADJTIME=0 -DHAVE_LONG_DOUBLE=1 -DHAVE_SETTIMEOFDAY=1 \
@@ -368,7 +340,12 @@
LDFLAGS= $(LFLAGS)

EXEEXT= .exe
-zic= ./host-zic
+HOST_ZIC= $(TOPDIR)/hostbin/zic$(EXEEXT)
+ifeq ($(CROSS_BUILD),1)
+zic= $(HOST_ZIC)
+else
+zic= zic$(EXEEXT)
+endif
ZIC= $(zic) $(ZFLAGS)

# The name of a Posix-compliant `awk' on your system.
@@ -508,7 +485,7 @@
$(UTIL) cp zdump.man $(MANDIR)/cat8/zdump.8
$(UTIL) cp zic.man $(MANDIR)/cat8/zic.8

-all: tzselect host-zic zic$(EXEEXT) zdump$(EXEEXT) $(LIBOBJS)
+all: tzselect $(HOST_ZIC) zic$(EXEEXT) zdump$(EXEEXT) $(LIBOBJS)

ALL: all date$(EXEEXT)

@@ -517,18 +494,23 @@
echo 'static char const TZVERSION[]="$(VERSION)";' && \
echo 'static char const REPORT_BUGS_TO[]="$(BUGEMAIL)";') >$@

-zdump$(EXEEXT): $(TZDOBJS)
- $(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(TZDOBJS) $(LDLIBS)
- $(CROSS_STRIP) $@
-
-host-zic: $(TZCSRCS) yearistype version.h
+zdump$(EXEEXT): $(TZDOBJS) $(TOPDIR)/lib/crt0.o $(TOPDIR)/lib/libc.a
+ $(CROSS_LD) -s $(LDFLAGS) $(TOPDIR)/lib/crt0.o $(TZDOBJS) -o $@
$(TOPDIR)/lib/libc.a $(LIBGCCA) -T $(DJGPP_DJL)
+ $(TOPDIR)/hostbin/stubify.exe $@
+
+ifneq ($(CROSS_BUILD),1)
+$(HOST_ZIC): zic$(EXEEXT)
+ $(UTIL) cp zic$(EXEEXT) $(HOST_ZIC)
+else
+$(HOST_ZIC): $(TZCSRCS) yearistype version.h
$(GCC) -DTZDIR=\"/dev/env/DJDIR~c:/djgpp~/zoneinfo\" \
$(GCCFLAGS) $(LDFLAGS) $(TZCSRCS) $(LDLIBS) -o $@
$(STRIP) $@
+endif

-zic$(EXEEXT): $(TZCOBJS) yearistype
- $(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(TZCOBJS) $(LDLIBS)
- $(CROSS_STRIP) $@
+zic$(EXEEXT): $(TZCOBJS) $(TOPDIR)/lib/crt0.o $(TOPDIR)/lib/libc.a yearistype
+ $(CROSS_LD) -s $(LDFLAGS) $(TOPDIR)/lib/crt0.o $(TZCOBJS) -o $@
$(TOPDIR)/lib/libc.a $(LIBGCCA) -T $(DJGPP_DJL)
+ $(TOPDIR)/hostbin/stubify.exe $@

yearistype: yearistype.sh
$(UTIL) cp yearistype.sh yearistype
@@ -578,15 +560,9 @@
-$(UTIL) mkdir $(LIBDIR)
$(CROSS_AR) rus $@ $(LIBOBJS)

-# We use the system's logwtmp in preference to ours if available.
-
-date$(EXEEXT): $(DATEOBJS)
- $(CROSS_AR) rs logwtmpl.a logwtmp.o
- $(CC) $(CFLAGS) date.o localtime.o asctime.o strftime.o \
- $(LDLIBS) -lc logwtmpl.a -o $@
- $(CROSS_STRIP) $@
- $(UTIL) rm logwtmpl.a
- $(CROSS_STRIP) $@
+date$(EXEEXT): $(DATEOBJS) $(TOPDIR)/lib/crt0.o $(TOPDIR)/lib/libc.a
+ $(CROSS_LD) -s $(LDFLAGS) $(TOPDIR)/lib/crt0.o $(DATEOBJS) -o $@
$(TOPDIR)/lib/libc.a $(LIBGCCA) -T $(DJGPP_DJL)
+ $(TOPDIR)/hostbin/stubify.exe $@

tzselect: tzselect.ksh
sed \
@@ -611,7 +587,7 @@

clean_misc:
$(UTIL) rm core *.o *.out tzselect zdump$(EXEEXT) zic$(EXEEXT) \
- yearistype date$(EXEEXT) logwtmpl* *.tar.gz host-zic *.exe *.man \
+ yearistype date$(EXEEXT) logwtmpl* *.tar.gz $(HOST_ZIC) *.exe *.man \
TDATA_list
clean: clean_misc
$(UTIL) rm -f -r tzpublic

--
O.S.

[DJ Delorie]

> * dxe3gen.c: change the variable length array from [] to [0] so that
> it compiles using gcc2

What happens if you turn array bounds checking on? Granted, this
isn't a system header so we have control over that, just wondering...

[DJ Delorie]

> - va_arg(argp, int); /* discard */
> + _ulonglong = va_arg(argp, int); /* discard */

Can we use (void)va_arg(...) instead, so the compiler doesn't ever
warn about (or try to optimize) an unused value? Or was the warning
about an uninitialized variable?

[Ozkan Sezer (sezeroz@gmail.com)]

On 5/23/15, DJ Delorie <d...@delorie.com> wrote:
>
>> * dxe3gen.c: change the variable length array from [] to [0] so that
>> it compiles using gcc2
>
> What happens if you turn array bounds checking on?

The same thing that would happen with search.h:struct qelem
or sys/system.h:_v1_stubinfo. Not ever tried though.

[Ozkan Sezer (sezeroz@gmail.com)]

On 5/23/15, DJ Delorie <d...@delorie.com> wrote:
>

The warning was 'computed value not used' or something like it, which
happened with gcc2.95, not with gcc3.3+.

As far as I can follow, that _ulonglong thing exists only for this
purpose, i.e. to discard the value (see the ARG() macro in there).
I _think_ we can instead use (void), but didn't try it myself (I don't
know how it would behave with __builtin_va_arg) and only followed the
existing style.

[Ozkan Sezer (sezeroz@gmail.com)]

Applied

[Andris Pavenis (andris.pavenis@iki.fi)]

Perhaps at least some hint could give GDB commit which caused that DJGPP port stopped to work (with
symptoms described earlier)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9b409511d07fe375284701af34909fb539029caf

Debugging DJGPP programs worked before this commit, but not after that. Used test executable for
testing whether GDB works OK was cc1.exe from my build of gcc-4.8.4 (HDDs are large now and I still
have build directory) in stage 3. Tested criteria: successful stepping into program, no error
messages, backtrace works reasonably well.

Andris

[Eli Zaretskii (eliz@gnu.org)]

> Date: Sun, 24 May 2015 11:17:27 +0300

> From: "Andris Pavenis (andris....@iki.fi)" <dj...@delorie.com>
>

> > So what and how goes wrong in the DJGPP build of GDB? Can someone
> > with enough free time step through the go32 initialization, and see
> > what's wrong there?
>
> Perhaps at least some hint could give GDB commit which caused that DJGPP port stopped to work (with
> symptoms described earlier)
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9b409511d07fe375284701af34909fb539029caf

Thanks!

Actually, it seems bd265cd0bde9e045ab5946532449430b66fe91ad, which is
a followup to the one you mentioned, is the bad commit. It seems a
simple case of misunderstanding the API conventions of our read_child
and write_child.

Can you try the patch below? If it fixes the problem, I will push it.

diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c
index f3966cd..852473b 100644
--- a/gdb/go32-nat.c
+++ b/gdb/go32-nat.c
@@ -587,6 +587,13 @@
else
res = read_child (memaddr, readbuf, len);

+ /* read_child and write_child return zero on success, non-zero on
+ failure; adjust the result value to that. */
+ if (res == 0)
+ res = len;
+ else
+ res = -1;
+
if (res <= 0)
return TARGET_XFER_E_IO;

[Juan Manuel Guerrero (juan.guerrero@gmx.de)]

I have tried the patch with gdb 7.9.1 and djgpp support seems to work again.
Neitherless sometimes backtrace and finish behave strange. Please give me
some time more to check. Especially with djgpp 2.05.

Regards,
Juan M. Guerrero

[Eli Zaretskii (eliz@gnu.org)]

> Date: Sun, 24 May 2015 14:48:32 +0200
> From: "Juan Manuel Guerrero (juan.g...@gmx.de)" <dj...@delorie.com>

>
> > Can you try the patch below? If it fixes the problem, I will push it.
> >
> > diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c
> > index f3966cd..852473b 100644
> > --- a/gdb/go32-nat.c
> > +++ b/gdb/go32-nat.c
> > @@ -587,6 +587,13 @@
> > else
> > res = read_child (memaddr, readbuf, len);
> >
> > + /* read_child and write_child return zero on success, non-zero on
> > + failure; adjust the result value to that. */
> > + if (res == 0)
> > + res = len;
> > + else
> > + res = -1;
> > +
> > if (res<= 0)
> > return TARGET_XFER_E_IO;
> >
>
> I have tried the patch with gdb 7.9.1 and djgpp support seems to work again.
> Neitherless sometimes backtrace and finish behave strange. Please give me
> some time more to check. Especially with djgpp 2.05.

Thanks for testing.

Is there a reason to withhold this patch? The issues you describe are
probably additional problems, unrelated to this one.

But if you'd like me to wait, I will.

[Juan Manuel Guerrero (juan.guerrero@gmx.de)]

If you known that the issues are not related to each other then there is no reason to withhold the patch.
Plaes go ahead an commit the patch.

Regards,
Juan M. Guerrero

[Eli Zaretskii (eliz@gnu.org)]

> Date: Sun, 24 May 2015 17:01:57 +0200

> From: "Juan Manuel Guerrero (juan.g...@gmx.de)" <dj...@delorie.com>
>

> If you known that the issues are not related to each other then there is no reason to withhold the patch.

> Please go ahead and commit the patch.

Thanks, I've posted the patch for review to the GDB mailing list, and
will commit in a few days, barring any objections.

[Juan Manuel Guerrero (juan.guerrero@gmx.de)]

OFYI,
I have compiled the repository code from yesterday using GCC 4.9.2 and GNU Binutils 2.24.
I have used -O0 -ggdb flags. This was intentional to be able to step into functions.
The produced library has been installed and used to compile GDB 7.9.1.

The following test program has been compiled using -O0 -ggdb:
------------- program start -------------
#include <stdio.h>


int print(const char *message)
{
int written;

written = printf("%s\n", message);

return written;
}

int main(void)
{
int written = 0;

written = print("qwertz");

return written;
}
------------- program end -------------

Steppinng into the code works well.
If I step into printf() and I issue the bt command I get the following
output:

(gdb) r
Starting program: c:/tmp/5/a.exe

Breakpoint 1, main () at a.c:15
15 int written = 0;
(gdb) s
17 written = print("qwertz");
(gdb)
print (message=0x1f35 <print+33> "qwertz") at a.c:8
8 written = printf("%s\n", message);
(gdb)
printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:10
10 {
(gdb)
printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:14
14 va_start(args, fmt);
(gdb) n
15 len = _doprnt(fmt, args, stdout);
(gdb) bt
#0 printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:15
#1 0x00003316 in nofpsig () at npxsetup.c:51
#2 0x00000006 in ?? ()
#3 0x00001f2a in print (message=0x1f35 <print+33> "qwertz") at a.c:8
#4 0x00001f61 in main () at a.c:17
(gdb)



The remarkable issue is that although I used the n command to avoid stepping
into _doprnt() gdb behaves as if the s command had been used. After having
stepped into _doprnt() I get the following output for the bt command:

10 {
(gdb)
printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:14
14 va_start(args, fmt);
(gdb) n
15 len = _doprnt(fmt, args, stdout);
(gdb) bt
#0 printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:15
#1 0x00003316 in nofpsig () at npxsetup.c:51
#2 0x00000006 in ?? ()
#3 0x00001f2a in print (message=0x1f35 <print+33> "qwertz") at a.c:8
#4 0x00001f61 in main () at a.c:17
(gdb) n
_doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n", argp=0x99b24 "5\037",
fp=0x11db0 <__dj_stdout>) at doprnt.c:119
119 {
(gdb)
148 locale_info = localeconv();
(gdb)
149 decimal_point = locale_info->decimal_point[0];
(gdb) bt
#0 _doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n", argp=0x99b24 "5\037",
fp=0x11db0 <__dj_stdout>) at doprnt.c:149
#1 0x00000000 in ?? ()
(gdb)



If I issue the finish command to run until the end of the function
I get the following output:

#0 printf (fmt=0x1f10 <_crt0_init_mcount+10> "%s\n") at printf.c:15
#1 0x00003316 in nofpsig () at npxsetup.c:51
#2 0x00000006 in ?? ()
#3 0x00001f2a in print (message=0x1f35 <print+33> "qwertz") at a.c:8
#4 0x00001f61 in main () at a.c:17
(gdb) n
_doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n", argp=0x99b24 "5\037",
fp=0x11db0 <__dj_stdout>) at doprnt.c:119
119 {
(gdb)
148 locale_info = localeconv();
(gdb)
149 decimal_point = locale_info->decimal_point[0];
(gdb) bt
#0 _doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n", argp=0x99b24 "5\037",
fp=0x11db0 <__dj_stdout>) at doprnt.c:149
#1 0x00000000 in ?? ()
(gdb) finish
Run till exit from #0 _doprnt (fmt0=0x1f10 <_crt0_init_mcount+10> "%s\n",
argp=0x99b24 "5\037", fp=0x11db0 <__dj_stdout>) at doprnt.c:149
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x0

(gdb)



If more information is required please let me know.

Regards,
Juan M. Guerrero

[Eli Zaretskii (eliz@gnu.org)]

> Date: Sun, 24 May 2015 17:46:42 +0200

> From: "Juan Manuel Guerrero (juan.g...@gmx.de)" <dj...@delorie.com>
>

> The following test program has been compiled using -O0 -ggdb:

What does -ggdb mean with the DJGPP build of GCC 4.9.2? It is better
to use an explicit debug info option (see below).

What does GDB say when you step into 'main' and type

(gdb) info source

One of the things it should announce is the type of debug info it
found in the program.

In any case, I suggest to try this experiment with all 3 debug info
types, COFF, stabs, and DWARF. To that end, instead of -ggdb, please
use "-gcoff -g3", "-gstabs -g3", and "-gdwarf-2 -g3", respectively.
(You could also try -gdwarf-3 and -gdwarf-4, not sure if the DJGPP
build of GCC supports that.)

This backtrace is obviously bogus: the 0x00000006 address cannot be an
address of any function, and nofpsig is not called by 'print'.

Can you try compiling the program with an older compiler, and try
debugging the program compiled by GCC 4.9.2 with a pre-7.7 version of
GDB? It's important to understand if this is a GCC bug or GDB bug.

[Andris Pavenis (andris.pavenis@iki.fi)]

I can confirm that with this patch applied I git current GIT master version of GDB to work for DJGPP:
- same example program cc1.exe from my earlier gcc-4.8.4 build used
- no error messages about accessing process memory
- backtrace somewhat unreliable but mostly works

Some small build problems:
- perhaps it would be best to kill dos_noop() in gdb-ser32.c and add appropriate static functions
instead (proptype of of one of them has changed in master branch, which caused compile error)
- got also DJGPP related compile error which is potentially related to latest changes, but I did
not have time to check whether it so

Also: Tried also cc1.exe from my last gcc-5.1.0 build with about the same results as with gcc-4.8.4
except that backtrace works sligthly worse.

Also: fails to read debug info from cc1.exe from gcc-6.0.0 20150506 snapshot build and complains
about dwarf error (could not find abbrev number 115 ....)

cc1.exe used from each tests were from stage 3 compile which is built by stage2 compiler of the
same version.

Andris

[Eli Zaretskii (eliz@gnu.org)]

> Date: Sun, 24 May 2015 23:36:54 +0300

> From: "Andris Pavenis (andris....@iki.fi)" <dj...@delorie.com>
>

> I can confirm that with this patch applied I git current GIT master version of GDB to work for DJGPP:
> - same example program cc1.exe from my earlier gcc-4.8.4 build used
> - no error messages about accessing process memory
> - backtrace somewhat unreliable but mostly works

Thanks for testing (and for bisecting the problem in the first place).

> Some small build problems:
> - perhaps it would be best to kill dos_noop() in gdb-ser32.c and add appropriate static functions
> instead (proptype of of one of them has changed in master branch, which caused compile error)
> - got also DJGPP related compile error which is potentially related to latest changes, but I did
> not have time to check whether it so

Please report the error messages, either here or to the GDB mailing
list.

[Andris Pavenis (andris.pavenis@iki.fi)]

On 05/25/2015 05:38 AM, Eli Zaretskii (el...@gnu.org) wrote:
> - got also DJGPP related compile error which is potentially related to latest changes, but I did
> not have time to check whether it so
> Please report the error messages, either here or to the GDB mailing
> list.
>

It is related to gdb/gnulib/import headers instead (included from gdb/djgpp/vsnprintf.c). This file
belongs to DJGPP related changes I rebased onto current master branch.

We do not need gdb/djgpp/vsnprintf.c for upcoming DJGPP v2.05, so I simply commented it out for
testing.

Andris

[Juan Manuel Guerrero (juan.guerrero@gmx.de)]

That file was required when porting for both djdev204 and djdev203. With djdev205 I will
no longer support neither djdev204 nor djdev203 and all those files taken from the repositors
will no longer be part of the port.

Regards,
Juan M. Guerrero

[Juan Manuel Guerrero (juan.guerrero@gmx.de)]

To make the long story short: the error was to use the -ggdb flag. The djgpp
port of gcc seems not to understand this. The right flag is -gdwarf-2. It is
also possible to compile with -gdwarf-3 and -gdwarf-4 but later the info source
command always claims that the debug format is DWARF2. It seems to be of no
benefit to use either the -gdwarf-3 or -gdwarf4 flag. Compiling with -gstabs
still works but makes no major sense to me because all source files must be
located in the same cwd or the debugger will not find them. Using -gcoff makes
no sense at all for debugging because it makes gdb crash like this:

C:\tmp\5>gdb a.exe
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i786-pc-msdosdjgpp --target=djgpp".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.exe...rmvfromfree: memory fouled
Exiting due to signal SIGABRT
Raised at eip=003f96da
eax=005440e4 ebx=00000120 ecx=00000011 edx=00000000 esi=00000198 edi=00000198
ebp=000001a8 esp=005440d0 program=C:\DJGPP-2.04\BIN\GDB.EXE
cs: sel=01a7 base=02990000 limit=006affff
ds: sel=01af base=02990000 limit=006affff
es: sel=01af base=02990000 limit=006affff
fs: sel=017f base=00008e80 limit=0000ffff
gs: sel=01bf base=00000000 limit=0010ffff
ss: sel=01af base=02990000 limit=006affff
App stack: [00544788..004c478c] Exceptn stack: [004c46e8..004c27a8]

Call frame traceback EIPs:
0x003f96da

C:\tmp\5>

I do not think it make sense to investigate this issue any more.


Using -gdwarf-2 makes work gdb again at least for the test cases I have tried.
The bt command works and also the step and next commands work as they should.
I do not understand why -ggdb did not work. I expected the port of the compiler
to be clever enough to know that -ggdb means -gdwarf-2 for a DJGPP port of gcc.
But it seems to be that I am wrong.

Regards,
Juan M. Guerrero

[Eli Zaretskii (eliz@gnu.org)]

> Date: Mon, 25 May 2015 07:11:04 +0300

> From: "Andris Pavenis (andris....@iki.fi)" <dj...@delorie.com>
>

If we don't need vsnprintf, then why does the configure script think
we do?

[Eli Zaretskii (eliz@gnu.org)]

> Date: Mon, 25 May 2015 14:44:08 +0200

> From: "Juan Manuel Guerrero (juan.g...@gmx.de)" <dj...@delorie.com>
>

> To make the long story short: the error was to use the -ggdb flag. The djgpp
> port of gcc seems not to understand this.

Thanks for looking into this. This should be reported to the GCC
maintainers (or maybe Andris will be able to fix that regardless).

> The right flag is -gdwarf-2. It is
> also possible to compile with -gdwarf-3 and -gdwarf-4 but later the info source
> command always claims that the debug format is DWARF2. It seems to be of no
> benefit to use either the -gdwarf-3 or -gdwarf4 flag.

That's a common misconception: -gdwarf-N actually generates debug info
according to DWARF Standard version N. GDB says it's all DWARF2 for
historical reasons.

You should be able to see the difference between the various values of
N by running "objdump --dwarf" on the executable and comparing the
output. (If the output is identical, then there's another bug in the
DJGPP port of GCC; GCC 4.8.1 provided by MinGW does support N=3 and
N=4, and the results are definitely different.)

Too bad: it means the new GCC/GDB are of no use for debugging Emacs.
Sounds like some memory allocation error to me.

> Using -gdwarf-2 makes work gdb again at least for the test cases I have tried.
> The bt command works and also the step and next commands work as they should.
> I do not understand why -ggdb did not work. I expected the port of the compiler
> to be clever enough to know that -ggdb means -gdwarf-2 for a DJGPP port of gcc.
> But it seems to be that I am wrong.

You are right; it's a bug in GCC.

Thanks.

[DJ Delorie]

> Too bad: it means the new GCC/GDB are of no use for debugging Emacs.

Why can't emacs use dwarf, like other platforms?

[Eli Zaretskii (eliz@gnu.org)]

> Date: Mon, 25 May 2015 14:25:25 -0400
> From: DJ Delorie <d...@delorie.com>

>
>
> > Too bad: it means the new GCC/GDB are of no use for debugging Emacs.
>
> Why can't emacs use dwarf, like other platforms?

Because last time I tried, the dumped Emacs segfaulted when temacs was
built with DWARF debug info, and no one cared enough, or had enough
resources, to fix that. (Most probably, we need to fix up something
in the debug info when we copy it from temacs to emacs.)

[Ozkan Sezer (sezeroz@gmail.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.

Some dxe3gen and dxe3res issues: They are not flexible with relation to
development environment:

1. As it seems, they were designed to be run under dos-djgpp not with a
cross-toolchain, i.e. dxe3gen expects 'gcc', 'as', 'ar' and 'ld' to be
djgpp-targeting tools. Well, ld _can_ be changed to be a cross-ld, but
only at compile time. User must have the ability to specify his choice
of tools.
- We may make dxe3gen to check environment variables such as DXE_CC,
DXE_AS, DXE_AR and DXE_LD whose values will be the names of the tools
of choice. (Maybe even a common DXE_CROSS_PREFIX to cover all those
at once??)
- Command line switches instead? (Environment vars seem better to me.)

2. Strict requirement for DXE_LD_LIBRARY_PATH environment is rude for
cross-compilers. It should be optional ifndef DJGPP

3. dxe3gen sends -T dxe.ld to ld, but the user can't specify a choice
of linker script. (One consequence is when compiling djgpp itself with
old toolchains, the toolchain-provided dxe.ld is used instead of the
one in the source tree.) Maybe add a '-T' switch to dxe3gen itself??

3. Both dxe3gen and dxe3res expect little endian host. On the other
hand, their father tool dxegen swaps bytes as required. Needs fixing.

Thoughts?

--
O.S.

[Ozkan Sezer (sezeroz@gmail.com)]

I was miserably wrong about the DXE_LD_LIBRARY_PATH. Noticed that I
was testing with some stale environment vars set

>
> 3. dxe3gen sends -T dxe.ld to ld, but the user can't specify a choice
> of linker script. (One consequence is when compiling djgpp itself with
> old toolchains, the toolchain-provided dxe.ld is used instead of the
> one in the source tree.) Maybe add a '-T' switch to dxe3gen itself??

. was wrong about the wrong script part too like above. (Sorry.)

[Louis Santillan (lpsantil@gmail.com)]

I have a minor 2.04 libc header bug that probably also exists 2.05. I
just recently ported lz4 [0] to djgpp via Andrew Wu's build-djgpp 2.04
cross compilers [1]. It's currently on the dev branch of lz4 and due
to be included on the next release of master.

In porting, I noticed that using `cc -std=c99` confuses the djgpp
headers such that the main bodies of the headers get nullified for
io.h, fcntl.h, and unistd.h. This is because `-std=c99` implies
`__STRICT_ANSI__` which is guarded against in those headers and
probably others. The simple work around is to instead use
`-std=gnu99` which does not imply `__STRICT_ANSI__` and brings in the
needed function prototypes (isatty(), setmode(), a couple others).


[0] https://github.com/lpsantil/lz4
[1] https://github.com/andrewwutw/build-djgpp/releases

> .. was wrong about the wrong script part too like above. (Sorry.)

[DJ Delorie]

We used the ISO standards as references when writing those headers.
If a function isn't in the ISO standard, it isn't declared when you
require a strict ISO/ANSI implementation. If the application expects
a non-ISO function in a header, and uses --std=c99, the application is
wrong.

Now, if the newer standards (c99/c11 vs c89) require more functions to
be declared in system headers, we should revisit that and protect
those functions accordingly.