• Difficulties compiling libc from repository using gcc 10.N.0

    From [via djgpp@delorie.com]" @21:1/5 to All on Thu Dec 10 11:55:29 2020
    I have tried to compile the the repository code of libc and the compiler stoped with the follwing error message:

    C:/DJGPP-2.05/BIN/make.exe -C common
    gcc ... -c dbgcom.c
    dbgcom.c: Assembler messages:
    dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already defined dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already defined make[3]: *** [../../makefile.inc:90: dbgcom.o] Error 1
    make[2]: *** [makefile.sub:2: all_subs] Error 2
    make[1]: *** [../makefile.lib:7: all] Error 2
    make: *** [makefile:45: subs] Error 2

    I have tried this using gcc1010 and gcc1020. Both fails. If I use gcc920 everything works fine. In all cases bnu234b has been used and no other one
    has been tried.


    Of course there are a lot of other warnings that aborts the compilation like: d:/djgpp/include/time.h: In function 'asctime':
    ctime.c:1553:55: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 12 [-Wformat-overflow=]
    1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",
    | ^~ ctime.c:1553:26: note: directive argument in the range [-2147481748, 2147483647]
    1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",
    | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ctime.c:1553:10: note: 'sprintf' output between 17 and 68 bytes into a destination of size 26
    1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",
    | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1554 | wday_name[timeptr->tm_wday],
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1555 | mon_name[timeptr->tm_mon],
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~
    1556 | timeptr->tm_mday, timeptr->tm_hour,
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1557 | timeptr->tm_min, timeptr->tm_sec,
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1558 | TM_YEAR_BASE + timeptr->tm_year);
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ d:/djgpp/include/time.h: In function 'ctime':
    ctime.c:1553:55: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 12 [-Wformat-overflow=]
    1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",
    | ^~ ctime.c:1553:26: note: directive argument in the range [-2147481748, 2147483647]
    1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",
    | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ctime.c:1553:10: note: 'sprintf' output between 17 and 68 bytes into a destination of size 26
    1553 | (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",
    | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1554 | wday_name[timeptr->tm_wday],
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1555 | mon_name[timeptr->tm_mon],
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~
    1556 | timeptr->tm_mday, timeptr->tm_hour,
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1557 | timeptr->tm_min, timeptr->tm_sec,
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1558 | TM_YEAR_BASE + timeptr->tm_year);
    | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    or:
    d:/djgpp/include/io.h: In function '_chmod':
    _chmod.c:28:14: warning: array subscript 1 is outside array bounds of 'int[1]' [-Warray-bounds]
    28 | r.x.cx = *(&func + 1); /* Value to set */
    | ^~~~~~~~~~~~
    _chmod.c:14:34: note: while referencing 'func'
    14 | _chmod(const char *filename, int func, ...)
    | ~~~~^~~~

    The -Warray-bounds appears quite a lot due to our way to address neighborhood variables as can
    be seen in the example above. May be some with some spare time can fix these occurencies.

    Regards,
    Juan M. Guerrero

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Thu Dec 10 14:55:44 2020
    C:/DJGPP-2.05/BIN/make.exe -C common
    gcc ... -c dbgcom.c
    dbgcom.c: Assembler messages:
    dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already defined dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already defined
    [...]
    I have tried this using gcc1010 and gcc1020. Both fails. If I use gcc920 everything works fine. In all cases bnu234b has been used and no other one has been tried.

    Some kind of gcc bug? How does the asm output of gcc look like?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Thu Dec 10 17:21:36 2020
    On 2020-12-10 11:55, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] wrote:
    I have tried to compile the the repository code of libc and the compiler stoped with the follwing error message:

    C:/DJGPP-2.05/BIN/make.exe -C common
    gcc ... -c dbgcom.c
    dbgcom.c: Assembler messages:
    dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already defined dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already defined make[3]: *** [../../makefile.inc:90: dbgcom.o] Error 1
    make[2]: *** [makefile.sub:2: all_subs] Error 2
    make[1]: *** [../makefile.lib:7: all] Error 2
    make: *** [makefile:45: subs] Error 2

    I have tried this using gcc1010 and gcc1020.  Both fails.  If I use gcc920 everything works fine.  In all cases bnu234b has been used and no other one has been tried.

    I ran into this also with gcc 9, I guess it depends on the optimization flags you specify (I like to use -O3). I think local labels should start with 'L' only (no leading '.'), that is also how gcc generates label names.

    If the asm is inlined into the same function twice, then you still have duplicate local labels and you need to add add %= to the label name which generates a unique ID for each asm instance.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Thu Dec 10 19:25:25 2020
    On 12/10/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    Am 10.12.2020 12:55, schrieb Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]:
    C:/DJGPP-2.05/BIN/make.exe -C common
    gcc ... -c dbgcom.c
    dbgcom.c: Assembler messages:
    dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already
    defined
    dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already
    defined
    [...]
    I have tried this using gcc1010 and gcc1020. Both fails. If I use
    gcc920
    everything works fine. In all cases bnu234b has been used and no other
    one
    has been tried.

    Some kind of gcc bug? How does the asm output of gcc look like?

    I have attached both assembly files, one produced by 9.2.0 and the other
    one
    produced by 10.2.0. The offending code starts at 1337 where some asm code
    is
    inserted. For some reason the labels used repeats a couple of times in the assembler output.

    gcc-10 -S format changed? It's a pain to read and impossible to
    diff against gcc-9 version.

    Nevertheless, gcc-10 seems to have inlined invalid_sel_addr()
    which has the asm, into read_sel_addr() hence the duplicated
    labels.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Thu Dec 10 17:38:22 2020
    On 2020-12-10 11:55, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] wrote:
    I have tried to compile the the repository code of libc and the compiler stoped with the follwing error message:

    C:/DJGPP-2.05/BIN/make.exe -C common
    gcc ... -c dbgcom.c
    dbgcom.c: Assembler messages:
    dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already defined dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already defined make[3]: *** [../../makefile.inc:90: dbgcom.o] Error 1
    make[2]: *** [makefile.sub:2: all_subs] Error 2
    make[1]: *** [../makefile.lib:7: all] Error 2
    make: *** [makefile:45: subs] Error 2

    I have tried this using gcc1010 and gcc1020.  Both fails.  If I use gcc920 everything works fine.  In all cases bnu234b has been used and no other one has been tried.


    Of course there are a lot of other warnings that aborts the compilation like: d:/djgpp/include/time.h: In function 'asctime':
    ctime.c:1553:55: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 12 [-Wformat-overflow=]
     1553 |   (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",       |                                                       ^~
    ctime.c:1553:26: note: directive argument in the range [-2147481748, 2147483647]
     1553 |   (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",       |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ctime.c:1553:10: note: 'sprintf' output between 17 and 68 bytes into a destination of size 26
     1553 |   (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     1554 |                  wday_name[timeptr->tm_wday],       |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~  1555 |                  mon_name[timeptr->tm_mon],       |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~  1556 |                  timeptr->tm_mday, timeptr->tm_hour,
          |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     1557 |                  timeptr->tm_min, timeptr->tm_sec,       |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     1558 |                  TM_YEAR_BASE + timeptr->tm_year);       |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    d:/djgpp/include/time.h: In function 'ctime':
    ctime.c:1553:55: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 12 [-Wformat-overflow=]
     1553 |   (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",       |                                                       ^~
    ctime.c:1553:26: note: directive argument in the range [-2147481748, 2147483647]
     1553 |   (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",       |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ctime.c:1553:10: note: 'sprintf' output between 17 and 68 bytes into a destination of size 26
     1553 |   (void) sprintf(result, "%.3s %.3s%3d %02d:%02d:%02d %d\n",       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     1554 |                  wday_name[timeptr->tm_wday],       |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~  1555 |                  mon_name[timeptr->tm_mon],       |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~  1556 |                  timeptr->tm_mday, timeptr->tm_hour,
          |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     1557 |                  timeptr->tm_min, timeptr->tm_sec,       |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     1558 |                  TM_YEAR_BASE + timeptr->tm_year);       |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


    or:
    d:/djgpp/include/io.h: In function '_chmod':
    _chmod.c:28:14: warning: array subscript 1 is outside array bounds of 'int[1]' [-Warray-bounds]
       28 |     r.x.cx = *(&func + 1);  /* Value to set */
          |              ^~~~~~~~~~~~
    _chmod.c:14:34: note: while referencing 'func'
       14 | _chmod(const char *filename, int func, ...)
          |                              ~~~~^~~~

    The -Warray-bounds appears quite a lot due to our way to address neighborhood variables as can
    be seen in the example above.  May be some with some spare time can fix these occurencies.

    Regards,
    Juan M. Guerrero

    Also note that linking will fail with gcc 10 since it now uses -fno-common by default, I worked around that with the following patch:

    ---
    src/debug/fsdb/makefile | 2 ++
    src/libc/ansi/stdlib/exit.c | 2 +-
    2 files changed, 3 insertions(+), 1 deletion(-)

    diff --git a/src/debug/fsdb/makefile b/src/debug/fsdb/makefile
    index da796d41..41f145fb 100644
    --- a/src/debug/fsdb/makefile
    +++ b/src/debug/fsdb/makefile
    @@ -12,6 +12,8 @@ EOBJS += unassmbl.o

    include $(TOP)/../makefile.inc

    +CFLAGS += -fcommon
    +
    #relax error checking:
    XGCC = $(XLGCC)

    diff --git a/src/libc/ansi/stdlib/exit.c b/src/libc/ansi/stdlib/exit.c
    index 94634b11..79b40ae9 100644
    --- a/src/libc/ansi/stdlib/exit.c
    +++ b/src/libc/ansi/stdlib/exit.c
    @@ -15,7 +15,7 @@

    struct __atexit *__atexit_ptr = 0;

    -void (*__stdio_cleanup_hook)(void);
    +extern void (*__stdio_cleanup_hook)(void);

    /* A hook to close down the file system extensions if any where opened.
    This does not force them to be linked in. */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Thu Dec 10 19:50:42 2020
    On 12/10/20, J.W. Jagersma (jwjagersma@gmail.com) [via
    djgpp@delorie.com] <djgpp@delorie.com> wrote:
    Also note that linking will fail with gcc 10 since it now uses -fno-common

    -fno-common can be a good thing..

    by default, I worked around that with the following patch:

    Which are the duplicated symbols causing trouble?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Thu Dec 10 18:03:00 2020
    On 2020-12-10 17:50, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
    On 12/10/20, J.W. Jagersma (jwjagersma@gmail.com) [via
    djgpp@delorie.com] <djgpp@delorie.com> wrote:
    Also note that linking will fail with gcc 10 since it now uses -fno-common

    -fno-common can be a good thing..

    by default, I worked around that with the following patch:

    Which are the duplicated symbols causing trouble?

    Only __stdio_cleanup_hook in libc, which I marked extern, and almost all global symbols in fsdb. I figured it would be okay to compile just fsdb with -fcommon.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Thu Dec 10 20:26:56 2020
    On 12/10/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    dbgcom.c: Assembler messages:
    dbgcom.c:1342: Error: symbol `.Ldoes_not_has_read_right' is already defined dbgcom.c:1346: Error: symbol `.Ldoes_not_has_write_right' is already defined

    On 12/10/20, Ozkan Sezer <sezeroz@gmail.com> wrote:
    Nevertheless, gcc-10 seems to have inlined invalid_sel_addr()
    which has the asm, into read_sel_addr() hence the duplicated
    labels.

    On 12/10/20, J.W. Jagersma (jwjagersma@gmail.com) [via
    djgpp@delorie.com] <djgpp@delorie.com> wrote:
    I ran into this also with gcc 9, I guess it depends on the optimization flags you specify (I like to use -O3). I think local labels should start with 'L' only (no leading '.'), that is also how gcc generates label names.

    If the asm is inlined into the same function twice, then you still have duplicate local labels and you need to add add %= to the label name which generates a unique ID for each asm instance.

    The attached patch appends "_%=" to .Ldoes_not_has_read_right
    and to .Ldoes_not_has_write_right labels.

    I tested to see that this avoids duplicated labels by marking invalid_sel_addr() as extern inline: using both gcc-2.95.3 and
    gcc-3.4.6, the build succeeds. OK to apply?

    --
    O.S.

    ZGJnY29tLmMgKGludmFsaWRfc2VsX2FkZHIpOiBhdm9pZCBkdXBsaWNhdGVkIGFzbSBsYWJlbHMg aWYgcHJvYyBpcyBpbmxpbmVkCgpJbmRleDogc3JjL2RlYnVnL2NvbW1vbi9kYmdjb20uYwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09ClJDUyBmaWxlOiAvY3ZzL2RqZ3BwL2RqZ3BwL3NyYy9kZWJ1Zy9jb21tb24vZGJnY29t LmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMzQKZGlmZiAtdSAtcCAtcjEuMzQgZGJnY29tLmMK LS0tIHNyYy9kZWJ1Zy9jb21tb24vZGJnY29tLmMJMiBNYXkgMjAxNSAwNzozMjowMCAtMDAwMAkx LjM0CisrKyBzcmMvZGVidWcvY29tbW9uL2RiZ2NvbS5jCTEwIERlYyAyMDIwIDE3OjE0OjA4IC0w MDAwCkBAIC0xMzM4LDEzICsxMzM4LDEzIEBAIGludCBpbnZhbGlkX3NlbF9hZGRyKHNob3J0IHNl bCwgdW5zaWduZWQKICAgICAoIgkJCQkJCQkJCQlcblwKICAgICAgIG1vdncgICUyLCUlYXgJCQkJ CQkJCVxuXAogICAgICAgdmVyciAgJSVheAkJCQkJCQkJXG5cCi0gICAgICBqbnogICAuTGRvZXNf bm90X2hhc19yZWFkX3JpZ2h0CQkJCQkJXG5cCisgICAgICBqbnogICAuTGRvZXNfbm90X2hhc19y ZWFkX3JpZ2h0XyU9CQkJCQlcblwKICAgICAgIG1vdmIgICQxLCUwCQkJCQkJCQlcblwKLS5MZG9l c19ub3RfaGFzX3JlYWRfcmlnaHQ6CQkJCQkJCVxuXAorLkxkb2VzX25vdF9oYXNfcmVhZF9yaWdo dF8lPToJCQkJCQkJXG5cCiAgICAgICB2ZXJ3ICAlJWF4CQkJCQkJCQlcblwKLSAgICAgIGpueiAg IC5MZG9lc19ub3RfaGFzX3dyaXRlX3JpZ2h0CQkJCQkJXG5cCisgICAgICBqbnogICAuTGRvZXNf bm90X2hhc193cml0ZV9yaWdodF8lPQkJCQkJXG5cCiAgICAgICBtb3ZiICAkMSwlMQkJCQkJCQkJ XG5cCi0uTGRvZXNfbm90X2hhc193cml0ZV9yaWdodDogIgorLkxkb2VzX25vdF9oYXNfd3JpdGVf cmlnaHRfJT06ICIKICAgICAgOiAiPXFtIiAocmVhZF9hbGxvd2VkKSwgIj1xbSIgKHdyaXRlX2Fs bG93ZWQpCiAgICAgIDogImciIChzZWwpCiAgICAgICk7Cg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Thu Dec 10 20:44:01 2020
    On 12/10/20, J.W. Jagersma (jwjagersma@gmail.com) [via
    djgpp@delorie.com] <djgpp@delorie.com> wrote:
    Which are the duplicated symbols causing trouble?

    Only __stdio_cleanup_hook in libc, which I marked extern, and almost all global
    symbols in fsdb. I figured it would be okay to compile just fsdb with -fcommon.

    The attached patch avoid duplicated symbols with gcc-10
    where -fno-common is on by default.

    The patch is from J. W. Jagersma, I only added comments.
    OK to apply?

    --
    O.S.

    YXZvaWQgZHVwbGljYXRlZCBzeW1ib2xzIHdpdGggZ2NjLTEwIHdoZXJlIC1mbm8tY29tbW9uIGlz IG9uIGJ5IGRlZmF1bHQKCnBhdGNoIGZyb20gSi4gVy4gSmFnZXJzbWEuCgpJbmRleDogc3JjL2Rl YnVnL2ZzZGIvbWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9kamdwcC9kamdwcC9z cmMvZGVidWcvZnNkYi9tYWtlZmlsZSx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4zCmRpZmYgLXUg LXAgLXIxLjMgbWFrZWZpbGUKLS0tIHNyYy9kZWJ1Zy9mc2RiL21ha2VmaWxlCTI3IFNlcCAxOTk4 IDE3OjA0OjI2IC0wMDAwCTEuMworKysgc3JjL2RlYnVnL2ZzZGIvbWFrZWZpbGUJMTAgRGVjIDIw MjAgMTc6Mzk6NDMgLTAwMDAKQEAgLTEyLDYgKzEyLDkgQEAgRU9CSlMgKz0gdW5hc3NtYmwubwog CiBpbmNsdWRlICQoVE9QKS8uLi9tYWtlZmlsZS5pbmMKIAorI3NlZSBzY3JlZW4uaCBhcyB0byB3 aHkgdGhpcyBpcyBuZWVkZWQKK0NGTEFHUyArPSAtZmNvbW1vbgorCiAjcmVsYXggZXJyb3IgY2hl Y2tpbmc6CiBYR0NDID0gJChYTEdDQykKIApJbmRleDogc3JjL2xpYmMvYW5zaS9zdGRsaWIvZXhp dC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvZGpncHAvZGpncHAvc3JjL2xpYmMvYW5zaS9z dGRsaWIvZXhpdC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjkKZGlmZiAtdSAtcCAtcjEuOSBl eGl0LmMKLS0tIHNyYy9saWJjL2Fuc2kvc3RkbGliL2V4aXQuYwkyIE1heSAyMDE1IDA3OjMyOjEw IC0wMDAwCTEuOQorKysgc3JjL2xpYmMvYW5zaS9zdGRsaWIvZXhpdC5jCTEwIERlYyAyMDIwIDE3 OjM5OjQzIC0wMDAwCkBAIC0xNSw3ICsxNSw3IEBACiAKIHN0cnVjdCBfX2F0ZXhpdCAqX19hdGV4 aXRfcHRyID0gMDsKIAotdm9pZCAoKl9fc3RkaW9fY2xlYW51cF9ob29rKSh2b2lkKTsKK2V4dGVy biB2b2lkICgqX19zdGRpb19jbGVhbnVwX2hvb2spKHZvaWQpOyAvKiBzdGRpby9zdGRpb2hrLmMg Ki8KIAogLyogQSBob29rIHRvIGNsb3NlIGRvd24gdGhlIGZpbGUgc3lzdGVtIGV4dGVuc2lvbnMg aWYgYW55IHdoZXJlIG9wZW5lZC4KICAgIFRoaXMgZG9lcyBub3QgZm9yY2UgdGhlbSB0byBiZSBs aW5rZWQgaW4uICovCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Thu Dec 10 20:25:47 2020
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Thu, 10 Dec 2020 20:44:01 +0300

    --- src/debug/fsdb/makefile 27 Sep 1998 17:04:26 -0000 1.3
    +++ src/debug/fsdb/makefile 10 Dec 2020 17:39:43 -0000
    @@ -12,6 +12,9 @@ EOBJS += unassmbl.o

    include $(TOP)/../makefile.inc

    +#see screen.h as to why this is needed
    +CFLAGS += -fcommon
    +

    This part looks OK.

    --- src/libc/ansi/stdlib/exit.c 2 May 2015 07:32:10 -0000 1.9
    +++ src/libc/ansi/stdlib/exit.c 10 Dec 2020 17:39:43 -0000
    @@ -15,7 +15,7 @@

    struct __atexit *__atexit_ptr = 0;

    -void (*__stdio_cleanup_hook)(void);
    +extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */

    This part I don't understand: are you saying that it is no longer the
    default that a function not explicitly declared 'static' has the
    external linkage? Why do we need an explicit 'extern' qualifier?

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Thu Dec 10 19:55:11 2020
    On 2020-12-10 19:25, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] wrote:
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Thu, 10 Dec 2020 20:44:01 +0300

    --- src/debug/fsdb/makefile 27 Sep 1998 17:04:26 -0000 1.3
    +++ src/debug/fsdb/makefile 10 Dec 2020 17:39:43 -0000
    @@ -12,6 +12,9 @@ EOBJS += unassmbl.o

    include $(TOP)/../makefile.inc

    +#see screen.h as to why this is needed
    +CFLAGS += -fcommon
    +

    This part looks OK.

    --- src/libc/ansi/stdlib/exit.c 2 May 2015 07:32:10 -0000 1.9
    +++ src/libc/ansi/stdlib/exit.c 10 Dec 2020 17:39:43 -0000
    @@ -15,7 +15,7 @@

    struct __atexit *__atexit_ptr = 0;

    -void (*__stdio_cleanup_hook)(void);
    +extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */

    This part I don't understand: are you saying that it is no longer the
    default that a function not explicitly declared 'static' has the
    external linkage? Why do we need an explicit 'extern' qualifier?

    Thanks.

    This only applies to global variables (and __stdio_cleanup_hook here is a function *pointer*), functions themselves still have implicit external linkage.

    I'm not a C language lawyer but this page suggests that it was always an error to omit 'extern' on global variable declarations. It just wasn't reported as such, until now:

    https://gcc.gnu.org/gcc-10/porting_to.html

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com on Thu Dec 10 21:56:27 2020
    On 12/10/20, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    --- src/libc/ansi/stdlib/exit.c 2 May 2015 07:32:10 -0000 1.9
    +++ src/libc/ansi/stdlib/exit.c 10 Dec 2020 17:39:43 -0000
    @@ -15,7 +15,7 @@

    struct __atexit *__atexit_ptr = 0;

    -void (*__stdio_cleanup_hook)(void);
    +extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */

    This part I don't understand: are you saying that it is no longer the
    default that a function not explicitly declared 'static' has the
    external linkage? Why do we need an explicit 'extern' qualifier?

    If I understand your question correctly, the function pointer __stdio_cleanup_hook is not static. It is defined both in stdlib/exit.c
    and in stdio/stdiohk.c, hence the issues with -fno-common.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Thu Dec 10 20:26:10 2020
    This is a multi-part message in MIME format.
    Am 10.12.2020 18:44, schrieb Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]:
    On 12/10/20, J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]<djgpp@delorie.com> wrote:
    Which are the duplicated symbols causing trouble?

    Only __stdio_cleanup_hook in libc, which I marked extern, and almost all global
    symbols in fsdb. I figured it would be okay to compile just fsdb with -fcommon.

    The attached patch avoid duplicated symbols with gcc-10
    where -fno-common is on by default.

    The patch is from J. W. Jagersma, I only added comments.
    OK to apply?

    --
    O.S.


    As has been told, a lot of these issues are triggered by different values of the -O flag. To get it compiled with -O2 the makefile of the djtar directory had to be adjusted accordingly. Of course, because we use -Werror the repository
    code does not compile out-of-the-box. So here a some work remains to be done for some one who has the time to fix all the issues.
    But with removed -Werror it compoiles so far.

    Regards,
    Juan M. Guerrero


    avoid duplicated symbols with gcc-10 where -fno-common is on by default

    patch from J. W. Jagersma.

    diff -aprNU3 djgpp.orig/src/utils/djtar/makefile djgpp/src/utils/djtar/makefile --- djgpp.orig/src/utils/djtar/makefile 2098-07-04 10:19:56 +0000
    +++ djgpp/src/utils/djtar/makefile 2020-12-10 19:34:14 +0000
    @@ -1,3 +1,4 @@
    +# Copyright (C) 2020 DJ Delorie, see COPYING.DJ for details
    # Copyright (C) 2015 DJ Delorie, see COPYING.DJ for details
    # Copyright (C) 2002 DJ Delorie, see COPYING.DJ for details
    # Copyright (C) 2000 DJ Delorie, see COPYING.DJ for details
    @@ -33,6 +34,9 @@ EXTRA_FILES += $(BIN)/djtart.exe
    include $(TOP)/../makefile.inc
    XGCC = $(XLGCC)

    +# Avoid duplicated symbols with gcc-10 where -fno-common is on by default. +CFLAGS += -fcommon
    +
    all :: $(BIN)/djtar.exe

    $(BIN)/djtar.exe : $(C) $(EOBJS) $(L)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Thu Dec 10 21:45:52 2020
    From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Thu, 10 Dec 2020 19:55:11 +0100

    -void (*__stdio_cleanup_hook)(void);
    +extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */

    This part I don't understand: are you saying that it is no longer the default that a function not explicitly declared 'static' has the
    external linkage? Why do we need an explicit 'extern' qualifier?

    Thanks.

    This only applies to global variables (and __stdio_cleanup_hook here is a function *pointer*), functions themselves still have implicit external linkage.

    And global variables don't?

    I'm not a C language lawyer but this page suggests that it was always an error
    to omit 'extern' on global variable declarations. It just wasn't reported as such, until now:

    https://gcc.gnu.org/gcc-10/porting_to.html

    That's got to break a lot of code, but OK.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Thu Dec 10 23:10:10 2020
    Applied the patch to debug/fsdb/makefile, utils/djtar/makefile,
    and libc/ansi/stdlib/exit.c

    Can someone review the dbgcom.patch ?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to djgpp@delorie.com] on Thu Dec 10 15:13:15 2020
    On 12/10/20 1:55 PM, J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com] wrote:
    This only applies to global variables (and __stdio_cleanup_hook here is a function *pointer*), functions themselves still have implicit external linkage.

    I'm not a C language lawyer but this page suggests that it was always an error
    to omit 'extern' on global variable declarations. It just wasn't reported as such, until now:

    https://gcc.gnu.org/gcc-10/porting_to.html

    Yes, The C Standard explicitly states that if two Translation Units
    define the same variable, it is undefined behavior.

    A Translation Unit is considered to define (vs declare) a variable if it
    is mentioned with the extern storage specifier.

    Many programs have broken this rule, but gcc (and others) have covered
    this issue with the -fcommon being assumed.

    --
    Richard Damon

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Thu Dec 10 21:22:19 2020
    Am 10.12.2020 21:10, schrieb Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]:
    Applied the patch to debug/fsdb/makefile, utils/djtar/makefile,
    and libc/ansi/stdlib/exit.c

    Can someone review the dbgcom.patch ?

    Apply it. It works.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Thu Dec 10 23:50:49 2020
    On 12/10/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    Am 10.12.2020 21:10, schrieb Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]:
    Applied the patch to debug/fsdb/makefile, utils/djtar/makefile,
    and libc/ansi/stdlib/exit.c

    Can someone review the dbgcom.patch ?

    Apply it. It works.

    Applied, thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker@21:1/5 to All on Thu Dec 10 22:19:33 2020
    Am 10.12.2020 um 20:45 schrieb Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]:
    From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Thu, 10 Dec 2020 19:55:11 +0100

    -void (*__stdio_cleanup_hook)(void);
    +extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */

    This part I don't understand: are you saying that it is no longer the
    default that a function not explicitly declared 'static' has the
    external linkage? Why do we need an explicit 'extern' qualifier?

    Thanks.

    This only applies to global variables (and __stdio_cleanup_hook here is a
    function *pointer*), functions themselves still have implicit external linkage.

    And global variables don't?

    Kind-a. In strict standard C, they do, but Unix C compilers have all
    had a common extension since the dawn of time_t: they expand the concept
    of "tentative definitions" (C99 6.9.2p2) from translation units to the
    entire program, i.e. a non-initialized definition effectively remains in "tentative" state until link-time. This extension was so wide-spread
    that it's actually listed in the C standard informative annex J.5.11.

    Or, to put it in terms of GCC options: -fcommon is againnst the C
    standard, but it has always been the Unix standard. The reason is
    hinted at by the name of the option: COMMON is a FORTRAN concept which
    Unix linkers had to support from the get-go, and it's technically
    equivalent to joining tentative definitions across translation units.
    (A FORTRAN named COMMON translates to a global, un-initialized struct
    variable. Individual translation units define it, then the linker puts
    them all in the same place.)

    So GCC 10 switched this default to the C standard-conforming value, -fno-common, and that will break code which relied on -fcommon without
    ever knowing it did.

    And BTW the correct solution of this issue is _not_ to just put "extern"
    in front of existing definitions, but rather to remove all but a single
    one of those entirely, and replace them by #includes of the header that
    does hold the corresponding extern declaration.

    Rules of thumb: never write "extern" in a *.c file, and never write
    "static" in a *.h file. You'll know when you're hitting an exception to
    this rule.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Fri Dec 11 00:39:32 2020
    On 12/10/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    d:/djgpp/include/io.h: In function '_chmod':
    _chmod.c:28:14: warning: array subscript 1 is outside array bounds of 'int[1]' [-Warray-bounds]
    28 | r.x.cx = *(&func + 1); /* Value to set */
    | ^~~~~~~~~~~~
    _chmod.c:14:34: note: while referencing 'func'
    14 | _chmod(const char *filename, int func, ...)
    | ~~~~^~~~

    The -Warray-bounds appears quite a lot due to our way to address
    neighborhood variables as can
    be seen in the example above. May be some with some spare time can fix
    these occurencies.

    As far as I can see, this particular case is intending this
    using a nasty shortcut?

    --- _chmod.c~
    +++ _chmod.c
    @@ -9,7 +9,8 @@
    #include <dpmi.h>
    #include <fcntl.h>
    #include <libc/dosio.h>
    -
    +#include <stdarg.h>
    +
    int
    _chmod(const char *filename, int func, ...)
    {
    @@ -25,7 +26,12 @@ _chmod(const char *filename, int func, .
    r.x.ax = 0x4300 + func;
    _put_path(filename);
    if (func == 1)
    - r.x.cx = *(&func + 1); /* Value to set */
    + {
    + va_list ap;
    + va_start (ap, func);
    + r.x.cx = va_arg(ap, int); /* Value to set */
    + va_end (ap);
    + }
    r.x.dx = __tb_offset;
    r.x.ds = __tb_segment;
    __dpmi_int(0x21, &r);

    Correct? Any others like this?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Fri Dec 11 01:43:37 2020
    Am 10.12.2020 22:39, schrieb Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]:
    On 12/10/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com]<djgpp@delorie.com> wrote:
    d:/djgpp/include/io.h: In function '_chmod':
    _chmod.c:28:14: warning: array subscript 1 is outside array bounds of
    'int[1]' [-Warray-bounds]
    28 | r.x.cx = *(&func + 1); /* Value to set */
    | ^~~~~~~~~~~~
    _chmod.c:14:34: note: while referencing 'func'
    14 | _chmod(const char *filename, int func, ...)
    | ~~~~^~~~

    The -Warray-bounds appears quite a lot due to our way to address
    neighborhood variables as can
    be seen in the example above. May be some with some spare time can fix
    these occurencies.

    As far as I can see, this particular case is intending this
    using a nasty shortcut?
    What is today a nasty shortcut was a cool one 30 years ago.


    --- _chmod.c~
    +++ _chmod.c
    @@ -9,7 +9,8 @@
    #include<dpmi.h>
    #include<fcntl.h>
    #include<libc/dosio.h>
    -
    +#include<stdarg.h>
    +
    int
    _chmod(const char *filename, int func, ...)
    {
    @@ -25,7 +26,12 @@ _chmod(const char *filename, int func, .
    r.x.ax = 0x4300 + func;
    _put_path(filename);
    if (func == 1)
    - r.x.cx = *(&func + 1); /* Value to set */
    + {
    + va_list ap;
    + va_start (ap, func);
    + r.x.cx = va_arg(ap, int); /* Value to set */
    + va_end (ap);
    + }
    r.x.dx = __tb_offset;
    r.x.ds = __tb_segment;
    __dpmi_int(0x21,&r);

    Correct? Any others like this?
    Looks ok to me. Will do the job; alternatively we would have to disable that check.

    Regards,
    Juan M. Guerrero

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Fri Dec 11 04:34:20 2020
    On 12/11/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    As far as I can see, this particular case is intending this
    using a nasty shortcut?
    What is today a nasty shortcut was a cool one 30 years ago.

    No arguments there.

    Correct? Any others like this?
    Looks ok to me. Will do the job; alternatively we would have to disable
    that check.

    Attached a patch that applies to current CVS.

    However, the asm outputs differ. Tried gcc-3.4.6 and gcc-8.2.0,
    asm outputs from both are attached here (*_0.s for original and
    *_1.s for patched.) Also attached diffs of *.s for convenience.
    Someone good with x86 asm should verify.

    SW5kZXg6IF9jaG1vZC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvZGpncHAvZGpncHAvc3Jj L2xpYmMvZG9zL2lvL19jaG1vZC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjYKZGlmZiAtdSAt cCAtcjEuNiBfY2htb2QuYwotLS0gX2NobW9kLmMJMTQgTWF5IDIwMTggMTY6NTY6NDEgLTAwMDAJ MS42CisrKyBfY2htb2QuYwkxMSBEZWMgMjAyMCAwMToyMDoyOCAtMDAwMApAQCAtOSw3ICs5LDgg QEAKICNpbmNsdWRlIDxkcG1pLmg+CiAjaW5jbHVkZSA8ZmNudGwuaD4KICNpbmNsdWRlIDxsaWJj L2Rvc2lvLmg+Ci0gCisjaW5jbHVkZSA8c3RkYXJnLmg+CisKIGludAogX2NobW9kKGNvbnN0IGNo YXIgKmZpbGVuYW1lLCBpbnQgZnVuYywgLi4uKQogewpAQCAtMjUsNyArMjYsMTIgQEAgX2NobW9k KGNvbnN0IGNoYXIgKmZpbGVuYW1lLCBpbnQgZnVuYywgLgogICAgIHIueC5heCA9IDB4NDMwMCAr IGZ1bmM7CiAgIF9wdXRfcGF0aChmaWxlbmFtZSk7CiAgIGlmIChmdW5jID09IDEpCi0gICAgci54 LmN4ID0gKigmZnVuYyArIDEpOwkJLyogVmFsdWUgdG8gc2V0ICovCisgIHsKKyAgICB2YV9saXN0 IGFwOworICAgIHZhX3N0YXJ0IChhcCwgZnVuYyk7CisgICAgci54LmN4ID0gdmFfYXJnIChhcCwg aW50KTsJCS8qIFZhbHVlIHRvIHNldCAqLworICAgIHZhX2VuZCAoYXApOworICB9CiAgIHIueC5k eCA9IF9fdGJfb2Zmc2V0OwogICByLnguZHMgPSBfX3RiX3NlZ21lbnQ7CiAgIF9fZHBtaV9pbnQo MHgyMSwgJnIpOwpAQCAtMzcsNiArNDMsNiBAQCBfY2htb2QoY29uc3QgY2hhciAqZmlsZW5hbWUs IGludCBmdW5jLCAuCiAgICAgZXJybm8gPSBfX2Rvc2Vycl90b19lcnJubyhyLnguYXgpOwogICAg IHJldHVybiAtMTsKICAgfQotIAorCiAgIHJldHVybiByLnguY3g7CiB9Cg== CS5maWxlCSJfY2htb2QuYyIKCS5zZWN0aW9uIC50ZXh0CgkucDJhbGlnbiA0LCwxNQouZ2xvYmwg X19jaG1vZApfX2NobW9kOgoJcHVzaGwJJWVicAoJbW92bAklZXNwLCAlZWJwCglzdWJsCSQ4NCwg JWVzcAoJcHVzaGwJJDAKCWNhbGwJX191c2VfbGZuCglhZGRsCSQxNiwgJWVzcAoJdGVzdGIJJWFs LCAlYWwKCWplCUwyCglzdWJsCSQxMiwgJWVzcAoJbW92bAkxMiglZWJwKSwgJWVheAoJbW92bAk4 KCVlYnApLCAlZWR4Cgltb3Z3CSQxLCAtNDAoJWVicCkKCW1vdncJJDI4OTk1LCAtNDQoJWVicCkK CW1vdmIJJWFsLCAtNTYoJWVicCkKCXB1c2hsCSVlZHgKCWNhbGwJX19wdXRfcGF0aAoJYWRkbAkk MTYsICVlc3AKCWNtcGwJJDEsIDEyKCVlYnApCglqZQlMOQpMNDoKCW1vdmwJX19nbzMyX2luZm9f YmxvY2srMTIsICVlYXgKCW1vdncJJDAsIC01MiglZWJwKQoJc2hybAkkNCwgJWVheAoJbW92dwkl YXgsIC0zNiglZWJwKQoJcHVzaGwJJWVheAoJcHVzaGwJJWVheAoJbGVhbAktNzIoJWVicCksICVl YXgKCXB1c2hsCSVlYXgKCXB1c2hsCSQzMwoJY2FsbAlfX19kcG1pX2ludAoJYWRkbAkkMTYsICVl c3AKCXRlc3RiCSQxLCAtNDAoJWVicCkKCWpuZQlMNwoJbW92bAktNDQoJWVicCksICVlYXgKCWNt cHcJJDI4OTI4LCAlYXgKCWplCUw2Cgltb3ZsCS00OCglZWJwKSwgJWVheAoJbGVhdmUKCWFuZGwJ JDY1NTM1LCAlZWF4CglyZXQKCS5wMmFsaWduIDQsLDcKTDI6CglzdWJsCSQxMiwgJWVzcAoJbW92 bAkxMiglZWJwKSwgJWVheAoJYWRkbAkkMTcxNTIsICVlYXgKCW1vdmwJOCglZWJwKSwgJWVkeAoJ bW92dwklYXgsIC00NCglZWJwKQoJcHVzaGwJJWVkeAoJY2FsbAlfX3B1dF9wYXRoCglhZGRsCSQx NiwgJWVzcAoJY21wbAkkMSwgMTIoJWVicCkKCWpuZQlMNApMOToKCW1vdmwJMTYoJWVicCksICVl YXgKCW1vdncJJWF4LCAtNDgoJWVicCkKCWptcAlMNApMNzoKCW1vdmwJLTQ0KCVlYnApLCAlZWF4 CgkucDJhbGlnbiA0LCw3Ckw2OgoJc3VibAkkMTIsICVlc3AKCWFuZGwJJDY1NTM1LCAlZWF4Cglw dXNobAklZWF4CgljYWxsCV9fX2Rvc2Vycl90b19lcnJubwoJbW92bAklZWF4LCBfZXJybm8KCW9y bAkkLTEsICVlYXgKCWxlYXZlCglyZXQKCS5pZGVudAkiR0NDOiAoR05VKSAzLjQuNiIK CS5maWxlCSJfY2htb2QuYyIKCS5zZWN0aW9uIC50ZXh0CgkucDJhbGlnbiA0LCwxNQouZ2xvYmwg X19jaG1vZApfX2NobW9kOgoJcHVzaGwJJWVicAoJbW92bAklZXNwLCAlZWJwCglwdXNobAklZWJ4 CglzdWJsCSQ4MCwgJWVzcAoJbW92bAkxMiglZWJwKSwgJWVieAoJcHVzaGwJJDAKCWNhbGwJX191 c2VfbGZuCglhZGRsCSQxNiwgJWVzcAoJdGVzdGIJJWFsLCAlYWwKCWplCUwyCglzdWJsCSQxMiwg JWVzcAoJbW92bAk4KCVlYnApLCAlZWR4Cgltb3ZiCSVibCwgLTU2KCVlYnApCgltb3Z3CSQxLCAt NDAoJWVicCkKCW1vdncJJDI4OTk1LCAtNDQoJWVicCkKCXB1c2hsCSVlZHgKCWNhbGwJX19wdXRf cGF0aAoJYWRkbAkkMTYsICVlc3AKCWRlY2wJJWVieAoJamUJTDkKTDQ6Cgltb3ZsCV9fZ28zMl9p bmZvX2Jsb2NrKzEyLCAlZWF4Cgltb3Z3CSQwLCAtNTIoJWVicCkKCXNocmwJJDQsICVlYXgKCW1v dncJJWF4LCAtMzYoJWVicCkKCXB1c2hsCSVlYXgKCXB1c2hsCSVlYXgKCWxlYWwJLTcyKCVlYnAp LCAlZWF4CglwdXNobAklZWF4CglwdXNobAkkMzMKCWNhbGwJX19fZHBtaV9pbnQKCWFkZGwJJDE2 LCAlZXNwCgl0ZXN0YgkkMSwgLTQwKCVlYnApCglqbmUJTDcKCW1vdmwJLTQ0KCVlYnApLCAlZWF4 CgljbXB3CSQyODkyOCwgJWF4CglqZQlMNgoJbW92bAktNDgoJWVicCksICVlYXgKCW1vdmwJLTQo JWVicCksICVlYngKCWFuZGwJJDY1NTM1LCAlZWF4CglsZWF2ZQoJcmV0CgkucDJhbGlnbiA0LCw3 CkwyOgoJc3VibAkkMTIsICVlc3AKCWxlYWwJMTcxNTIoJWVieCksICVlYXgKCW1vdmwJOCglZWJw KSwgJWVkeAoJbW92dwklYXgsIC00NCglZWJwKQoJcHVzaGwJJWVkeAoJY2FsbAlfX3B1dF9wYXRo CglhZGRsCSQxNiwgJWVzcAoJZGVjbAklZWJ4CglqbmUJTDQKTDk6Cgltb3ZsCTE2KCVlYnApLCAl ZWF4Cgltb3Z3CSVheCwgLTQ4KCVlYnApCglqbXAJTDQKTDc6Cgltb3ZsCS00NCglZWJwKSwgJWVh eAoJLnAyYWxpZ24gNCwsNwpMNjoKCXN1YmwJJDEyLCAlZXNwCglhbmRsCSQ2NTUzNSwgJWVheAoJ cHVzaGwJJWVheAoJY2FsbAlfX19kb3NlcnJfdG9fZXJybm8KCW1vdmwJJWVheCwgX2Vycm5vCglv cmwJJC0xLCAlZWF4Cgltb3ZsCS00KCVlYnApLCAlZWJ4CglsZWF2ZQoJcmV0CgkuaWRlbnQJIkdD QzogKEdOVSkgMy40LjYiCg== LS0tIGdjYzM0XzAucworKysgZ2NjMzRfMS5zCkBAIC01LDIyICs1LDIzIEBACiBfX2NobW9kOgog CXB1c2hsCSVlYnAKIAltb3ZsCSVlc3AsICVlYnAKKwlwdXNobAklZWJ4Ci0Jc3VibAkkODQsICVl c3AKKwlzdWJsCSQ4MCwgJWVzcAorCW1vdmwJMTIoJWVicCksICVlYngKIAlwdXNobAkkMAogCWNh bGwJX191c2VfbGZuCiAJYWRkbAkkMTYsICVlc3AKIAl0ZXN0YgklYWwsICVhbAogCWplCUwyCiAJ c3VibAkkMTIsICVlc3AKLQltb3ZsCTEyKCVlYnApLCAlZWF4CiAJbW92bAk4KCVlYnApLCAlZWR4 CisJbW92YgklYmwsIC01NiglZWJwKQogCW1vdncJJDEsIC00MCglZWJwKQogCW1vdncJJDI4OTk1 LCAtNDQoJWVicCkKLQltb3ZiCSVhbCwgLTU2KCVlYnApCiAJcHVzaGwJJWVkeAogCWNhbGwJX19w dXRfcGF0aAogCWFkZGwJJDE2LCAlZXNwCi0JY21wbAkkMSwgMTIoJWVicCkKKwlkZWNsCSVlYngK IAlqZQlMOQogTDQ6CiAJbW92bAlfX2dvMzJfaW5mb19ibG9jaysxMiwgJWVheApAQCAtNDAsMjAg KzQxLDIwIEBACiAJY21wdwkkMjg5MjgsICVheAogCWplCUw2CiAJbW92bAktNDgoJWVicCksICVl YXgKLQlsZWF2ZQorCW1vdmwJLTQoJWVicCksICVlYngKIAlhbmRsCSQ2NTUzNSwgJWVheAorCWxl YXZlCiAJcmV0CiAJLnAyYWxpZ24gNCwsNwogTDI6CiAJc3VibAkkMTIsICVlc3AKLQltb3ZsCTEy KCVlYnApLCAlZWF4Ci0JYWRkbAkkMTcxNTIsICVlYXgKKwlsZWFsCTE3MTUyKCVlYngpLCAlZWF4 CiAJbW92bAk4KCVlYnApLCAlZWR4CiAJbW92dwklYXgsIC00NCglZWJwKQogCXB1c2hsCSVlZHgK IAljYWxsCV9fcHV0X3BhdGgKIAlhZGRsCSQxNiwgJWVzcAotCWNtcGwJJDEsIDEyKCVlYnApCisJ ZGVjbAklZWJ4CiAJam5lCUw0CiBMOToKIAltb3ZsCTE2KCVlYnApLCAlZWF4CkBAIC02OSw2ICs3 MCw3IEBACiAJY2FsbAlfX19kb3NlcnJfdG9fZXJybm8KIAltb3ZsCSVlYXgsIF9lcnJubwogCW9y bAkkLTEsICVlYXgKKwltb3ZsCS00KCVlYnApLCAlZWJ4CiAJbGVhdmUKIAlyZXQKIAkuaWRlbnQJ IkdDQzogKEdOVSkgMy40LjYiCg== CS5maWxlCSJfY2htb2QuYyIKCS5zZWN0aW9uIC50ZXh0CgkucDJhbGlnbiA0LCwxNQoJLmdsb2Js CV9fY2htb2QKX19jaG1vZDoKTEZCMzoKCS5jZmlfc3RhcnRwcm9jCglwdXNobAklZWJ4CgkuY2Zp X2RlZl9jZmFfb2Zmc2V0IDgKCS5jZmlfb2Zmc2V0IDMsIC04CglzdWJsCSQ4NCwgJWVzcAoJLmNm aV9kZWZfY2ZhX29mZnNldCA5MgoJcHVzaGwJJDAKCS5jZmlfZGVmX2NmYV9vZmZzZXQgOTYKCWNh bGwJX191c2VfbGZuCgltb3ZsCTEwMCglZXNwKSwgJWVieAoJYWRkbAkkMTYsICVlc3AKCS5jZmlf ZGVmX2NmYV9vZmZzZXQgODAKCXRlc3RiCSVhbCwgJWFsCglqZQlMMgoJbW92dwkkMSwgNDQoJWVz cCkKCW1vdncJJDI4OTk1LCA0MCglZXNwKQoJbW92YgklYmwsIDI4KCVlc3ApCkwzOgoJc3VibAkk MTIsICVlc3AKCS5jZmlfZGVmX2NmYV9vZmZzZXQgOTIKCW1vdmwJOTIoJWVzcCksICVlZHgKCXB1 c2hsCSVlZHgKCS5jZmlfZGVmX2NmYV9vZmZzZXQgOTYKCWNhbGwJX19wdXRfcGF0aAoJYWRkbAkk MTYsICVlc3AKCS5jZmlfZGVmX2NmYV9vZmZzZXQgODAKCWRlY2wJJWVieAoJam5lCUw0Cgltb3Zs CTg4KCVlc3ApLCAlZWF4Cgltb3Z3CSVheCwgMzYoJWVzcCkKTDQ6Cgltb3ZsCV9fZ28zMl9pbmZv X2Jsb2NrKzEyLCAlZWF4Cgltb3Z3CSQwLCAzMiglZXNwKQoJc2hybAkkNCwgJWVheAoJbW92dwkl YXgsIDQ4KCVlc3ApCglwdXNobAklZWF4CgkuY2ZpX2RlZl9jZmFfb2Zmc2V0IDg0CglwdXNobAkl ZWF4CgkuY2ZpX2RlZl9jZmFfb2Zmc2V0IDg4CglsZWFsCTIwKCVlc3ApLCAlZWF4CglwdXNobAkl ZWF4CgkuY2ZpX2RlZl9jZmFfb2Zmc2V0IDkyCglwdXNobAkkMzMKCS5jZmlfZGVmX2NmYV9vZmZz ZXQgOTYKCWNhbGwJX19fZHBtaV9pbnQKCWFkZGwJJDE2LCAlZXNwCgkuY2ZpX2RlZl9jZmFfb2Zm c2V0IDgwCgltb3ZsCTQwKCVlc3ApLCAlZWF4Cgl0ZXN0YgkkMSwgNDQoJWVzcCkKCWpuZQlMNgoJ Y21wdwkkMjg5MjgsICVheAoJamUJTDYKCXhvcmwJJWVheCwgJWVheAoJbW92dwkzNiglZXNwKSwg JWF4CkwxOgoJYWRkbAkkNzIsICVlc3AKCS5jZmlfcmVtZW1iZXJfc3RhdGUKCS5jZmlfZGVmX2Nm YV9vZmZzZXQgOAoJcG9wbAklZWJ4CgkuY2ZpX3Jlc3RvcmUgMwoJLmNmaV9kZWZfY2ZhX29mZnNl dCA0CglyZXQKCS5wMmFsaWduIDQsLDcKTDI6CgkuY2ZpX3Jlc3RvcmVfc3RhdGUKCWxlYWwJMTcx NTIoJWVieCksICVlYXgKCW1vdncJJWF4LCA0MCglZXNwKQoJam1wCUwzCgkucDJhbGlnbiA0LCw3 Ckw2OgoJc3VibAkkMTIsICVlc3AKCS5jZmlfZGVmX2NmYV9vZmZzZXQgOTIKCWFuZGwJJDY1NTM1 LCAlZWF4CglwdXNobAklZWF4CgkuY2ZpX2RlZl9jZmFfb2Zmc2V0IDk2CgljYWxsCV9fX2Rvc2Vy cl90b19lcnJubwoJYWRkbAkkMTYsICVlc3AKCS5jZmlfZGVmX2NmYV9vZmZzZXQgODAKCW1vdmwJ JWVheCwgX2Vycm5vCglvcmwJJC0xLCAlZWF4CglqbXAJTDEKCS5jZmlfZW5kcHJvYwpMRkUzOgoJ LmlkZW50CSJHQ0M6IChHTlUpIDguMi4wIgo= CS5maWxlCSJfY2htb2QuYyIKCS5zZWN0aW9uIC50ZXh0CgkucDJhbGlnbiA0LCwxNQoJLmdsb2Js CV9fY2htb2QKX19jaG1vZDoKTEZCMzoKCS5jZmlfc3RhcnRwcm9jCglwdXNobAklZWJ4CgkuY2Zp X2RlZl9jZmFfb2Zmc2V0IDgKCS5jZmlfb2Zmc2V0IDMsIC04CglzdWJsCSQ4NCwgJWVzcAoJLmNm aV9kZWZfY2ZhX29mZnNldCA5MgoJbW92bAk5NiglZXNwKSwgJWVieAoJcHVzaGwJJDAKCS5jZmlf ZGVmX2NmYV9vZmZzZXQgOTYKCWNhbGwJX191c2VfbGZuCglhZGRsCSQxNiwgJWVzcAoJLmNmaV9k ZWZfY2ZhX29mZnNldCA4MAoJdGVzdGIJJWFsLCAlYWwKCWplCUwyCgltb3Z3CSQxLCA0NCglZXNw KQoJbW92dwkkMjg5OTUsIDQwKCVlc3ApCgltb3ZiCSVibCwgMjgoJWVzcCkKTDM6CglzdWJsCSQx MiwgJWVzcAoJLmNmaV9kZWZfY2ZhX29mZnNldCA5MgoJbW92bAk5MiglZXNwKSwgJWVkeAoJcHVz aGwJJWVkeAoJLmNmaV9kZWZfY2ZhX29mZnNldCA5NgoJY2FsbAlfX3B1dF9wYXRoCglhZGRsCSQx NiwgJWVzcAoJLmNmaV9kZWZfY2ZhX29mZnNldCA4MAoJZGVjbAklZWJ4CglqZQlMMTEKTDQ6Cglt b3ZsCV9fZ28zMl9pbmZvX2Jsb2NrKzEyLCAlZWF4Cgltb3Z3CSQwLCAzMiglZXNwKQoJc2hybAkk NCwgJWVheAoJbW92dwklYXgsIDQ4KCVlc3ApCglwdXNobAklZWF4CgkuY2ZpX2RlZl9jZmFfb2Zm c2V0IDg0CglwdXNobAklZWF4CgkuY2ZpX2RlZl9jZmFfb2Zmc2V0IDg4CglsZWFsCTIwKCVlc3Ap LCAlZWF4CglwdXNobAklZWF4CgkuY2ZpX2RlZl9jZmFfb2Zmc2V0IDkyCglwdXNobAkkMzMKCS5j ZmlfZGVmX2NmYV9vZmZzZXQgOTYKCWNhbGwJX19fZHBtaV9pbnQKCWFkZGwJJDE2LCAlZXNwCgku Y2ZpX2RlZl9jZmFfb2Zmc2V0IDgwCgltb3ZsCTQwKCVlc3ApLCAlZWF4Cgl0ZXN0YgkkMSwgNDQo JWVzcCkKCWpuZQlMNgoJY21wdwkkMjg5MjgsICVheAoJamUJTDYKCXhvcmwJJWVheCwgJWVheAoJ bW92dwkzNiglZXNwKSwgJWF4CkwxOgoJYWRkbAkkNzIsICVlc3AKCS5jZmlfcmVtZW1iZXJfc3Rh dGUKCS5jZmlfZGVmX2NmYV9vZmZzZXQgOAoJcG9wbAklZWJ4CgkuY2ZpX3Jlc3RvcmUgMwoJLmNm aV9kZWZfY2ZhX29mZnNldCA0CglyZXQKCS5wMmFsaWduIDQsLDcKTDI6CgkuY2ZpX3Jlc3RvcmVf c3RhdGUKCWxlYWwJMTcxNTIoJWVieCksICVlYXgKCW1vdncJJWF4LCA0MCglZXNwKQoJam1wCUwz CgkucDJhbGlnbiA0LCw3CkwxMToKCW1vdmwJODgoJWVzcCksICVlYXgKCW1vdncJJWF4LCAzNigl ZXNwKQoJam1wCUw0CgkucDJhbGlnbiA0LCw3Ckw2OgoJc3VibAkkMTIsICVlc3AKCS5jZmlfZGVm X2NmYV9vZmZzZXQgOTIKCWFuZGwJJDY1NTM1LCAlZWF4CglwdXNobAklZWF4CgkuY2ZpX2RlZl9j ZmFfb2Zmc2V0IDk2CgljYWxsCV9fX2Rvc2Vycl90b19lcnJubwoJYWRkbAkkMTYsICVlc3AKCS5j ZmlfZGVmX2NmYV9vZmZzZXQgODAKCW1vdmwJJWVheCwgX2Vycm5vCglvcmwJJC0xLCAlZWF4Cglq bXAJTDEKCS5jZmlfZW5kcHJvYwpMRkUzOgoJLmlkZW50CSJHQ0M6IChHTlUpIDguMi4wIgo= LS0tIGdjYzgyXzAucworKysgZ2NjODJfMS5zCkBAIC0xMCwxMCArMTAsMTAgQEAKIAkuY2ZpX29m ZnNldCAzLCAtOAogCXN1YmwJJDg0LCAlZXNwCiAJLmNmaV9kZWZfY2ZhX29mZnNldCA5MgorCW1v dmwJOTYoJWVzcCksICVlYngKIAlwdXNobAkkMAogCS5jZmlfZGVmX2NmYV9vZmZzZXQgOTYKIAlj YWxsCV9fdXNlX2xmbgotCW1vdmwJMTAwKCVlc3ApLCAlZWJ4CiAJYWRkbAkkMTYsICVlc3AKIAku Y2ZpX2RlZl9jZmFfb2Zmc2V0IDgwCiAJdGVzdGIJJWFsLCAlYWwKQEAgLTMxLDkgKzMxLDcgQEAK IAlhZGRsCSQxNiwgJWVzcAogCS5jZmlfZGVmX2NmYV9vZmZzZXQgODAKIAlkZWNsCSVlYngKLQlq bmUJTDQKLQltb3ZsCTg4KCVlc3ApLCAlZWF4Ci0JbW92dwklYXgsIDM2KCVlc3ApCisJamUJTDEx CiBMNDoKIAltb3ZsCV9fZ28zMl9pbmZvX2Jsb2NrKzEyLCAlZWF4CiAJbW92dwkkMCwgMzIoJWVz cCkKQEAgLTczLDYgKzcxLDExIEBACiAJbW92dwklYXgsIDQwKCVlc3ApCiAJam1wCUwzCiAJLnAy YWxpZ24gNCwsNworTDExOgorCW1vdmwJODgoJWVzcCksICVlYXgKKwltb3Z3CSVheCwgMzYoJWVz cCkKKwlqbXAJTDQKKwkucDJhbGlnbiA0LCw3CiBMNjoKIAlzdWJsCSQxMiwgJWVzcAogCS5jZmlf ZGVmX2NmYV9vZmZzZXQgOTIK

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to Ozkan Sezer on Sun Dec 13 20:52:23 2020
    On 12/11/20, Ozkan Sezer <sezeroz@gmail.com> wrote:
    On 12/11/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    As far as I can see, this particular case is intending this
    using a nasty shortcut?
    What is today a nasty shortcut was a cool one 30 years ago.

    No arguments there.

    Correct? Any others like this?
    Looks ok to me. Will do the job; alternatively we would have to disable
    that check.

    Attached a patch that applies to current CVS.

    However, the asm outputs differ. Tried gcc-3.4.6 and gcc-8.2.0,
    asm outputs from both are attached here (*_0.s for original and
    *_1.s for patched.) Also attached diffs of *.s for convenience.
    Someone good with x86 asm should verify.

    Has anyone had a chance to look at this?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Wed Dec 16 02:20:17 2020
    Am 13.12.2020 18:52, schrieb Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]:
    On 12/11/20, Ozkan Sezer<sezeroz@gmail.com> wrote:
    On 12/11/20, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com]<djgpp@delorie.com> wrote:
    As far as I can see, this particular case is intending this
    using a nasty shortcut?
    What is today a nasty shortcut was a cool one 30 years ago.

    No arguments there.

    Correct? Any others like this?
    Looks ok to me. Will do the job; alternatively we would have to disable >>> that check.

    Attached a patch that applies to current CVS.

    However, the asm outputs differ. Tried gcc-3.4.6 and gcc-8.2.0,
    asm outputs from both are attached here (*_0.s for original and
    *_1.s for patched.) Also attached diffs of *.s for convenience.
    Someone good with x86 asm should verify.

    Has anyone had a chance to look at this?

    IMHO it makes not to much sense to compare the assembly code. It is clear that different code will produce different assembly output. I do not even know how the va_* macros are implemented and if they are provided by the libc code or by the compiler as build-in features. The only important thing is that the proposed
    code is functional equivalent to the one that shall be substituted. I have tried to prove this with the small modification shown below and with a test program that first reads the attribute then sets the read-only bit and writes back the attribute. I have done this with gcc345 and gcc1020 and in both case it did work for me. From my point of view the proposed fix is ok but it is only
    opinion.

    Regards,
    Juan M. Guerrero





    OFYI, the small check code:


    diff -aprNU3 djgpp.orig/src/1.c djgpp/src/1.c
    --- djgpp.orig/src/1.c 1970-01-01 00:00:00 +0000
    +++ djgpp/src/1.c 2020-12-15 12:51:32 +0000
    @@ -0,0 +1,20 @@
    +#include <stdio.h>
    +#include <io.h>
    +
    +int main(void)
    +{
    + int f, m, rc;
    +
    + f = 0;
    + rc = _chmod("1.c", f);
    + if (rc != -1)
    + {
    + m = rc | 0x00000001;
    + f = 1;
    + rc = _chmod("1.c", f, m);
    + }
    + if (rc == -1)
    + printf("failed");
    +
    + return rc;
    +}
    diff -aprNU3 djgpp.orig/src/libc/dos/io/_chmod.c djgpp/src/libc/dos/io/_chmod.c --- djgpp.orig/src/libc/dos/io/_chmod.c 2018-05-14 16:56:40 +0000
    +++ djgpp/src/libc/dos/io/_chmod.c 2020-12-15 12:51:26 +0000
    @@ -9,7 +9,9 @@
    #include <dpmi.h>
    #include <fcntl.h>
    #include <libc/dosio.h>
    -
    +#include <stdarg.h>
    +#include <stdlib.h>
    +
    int
    _chmod(const char *filename, int func, ...)
    {
    @@ -25,7 +27,16 @@ _chmod(const char *filename, int func, .
    r.x.ax = 0x4300 + func;
    _put_path(filename);
    if (func == 1)
    - r.x.cx = *(&func + 1); /* Value to set */
    + {
    + int v1, v2 = *(&fun
  • From [via djgpp@delorie.com]" @21:1/5 to All on Wed Jan 13 19:31:46 2021
    The v1.2 commit to machine/endian.h defined some macros which may be problematic, e.g. __BIG_ENDIAN__: notice the leading _and_ trailing double-underscores. http://www.delorie.com/bin/cvsweb.cgi/djgpp/include/machine/endian.h

    Gcc from big-endian targeting toolchains have a tendency for defining __BIG_ENDIAN__, e.g.:

    $ /opt/cross_osx-ppc/bin/powerpc-apple-darwin9-gcc -E -dD -xc /dev/null | \
    grep ENDIAN
    #define __BIG_ENDIAN__ 1
    #define _BIG_ENDIAN 1

    $ /gg/bin/ppc-morphos-gcc -E -dD -xc /dev/null | grep ENDIAN
    #define __BIG_ENDIAN__ 1
    #define _BIG_ENDIAN 1

    $ /opt/cross_amigaos4/bin/ppc-amigaos-gcc -E -dD -xc /dev/null | \
    grep ENDIAN
    #define __BIG_ENDIAN__ 1
    #define _BIG_ENDIAN 1

    I suggest removing the additional macros with both leading and trailing double-underscores, i.e. like the following patch:

    Index: include/machine/endian.h ===================================================================
    RCS file: /cvs/djgpp/djgpp/include/machine/endian.h,v
    retrieving revision 1.2
    diff -u -r1.2 endian.h
    --- include/machine/endian.h 6 Jan 2021 14:55:05 -0000 1.2
    +++ include/machine/endian.h 13 Jan 2021 16:23:19 -0000
    @@ -54,11 +54,6 @@
    #define __PDP_ENDIAN PDP_ENDIAN
    #define __BYTE_ORDER LITTLE_ENDIAN

    -#define __LITTLE_ENDIAN__ LITTLE_ENDIAN
    -#define __BIG_ENDIAN__ BIG_ENDIAN
    -#define __PDP_ENDIAN__ PDP_ENDIAN
    -#define __BYTE_ORDER__ LITTLE_ENDIAN
    -

    #include <sys/cdefs.h>


    --
    O.S.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to Ozkan Sezer on Thu Jan 14 21:15:35 2021
    On 1/13/21, Ozkan Sezer <sezeroz@gmail.com> wrote:
    The v1.2 commit to machine/endian.h defined some macros which may be problematic, e.g. __BIG_ENDIAN__: notice the leading _and_ trailing double-underscores. http://www.delorie.com/bin/cvsweb.cgi/djgpp/include/machine/endian.h

    Gcc from big-endian targeting toolchains have a tendency for defining __BIG_ENDIAN__, e.g.:

    $ /opt/cross_osx-ppc/bin/powerpc-apple-darwin9-gcc -E -dD -xc /dev/null | \
    grep ENDIAN
    #define __BIG_ENDIAN__ 1
    #define _BIG_ENDIAN 1

    $ /gg/bin/ppc-morphos-gcc -E -dD -xc /dev/null | grep ENDIAN
    #define __BIG_ENDIAN__ 1
    #define _BIG_ENDIAN 1

    $ /opt/cross_amigaos4/bin/ppc-amigaos-gcc -E -dD -xc /dev/null | \
    grep ENDIAN
    #define __BIG_ENDIAN__ 1
    #define _BIG_ENDIAN 1

    I suggest removing the additional macros with both leading and trailing double-underscores, i.e. like the following patch:

    Index: include/machine/endian.h ===================================================================
    RCS file: /cvs/djgpp/djgpp/include/machine/endian.h,v
    retrieving revision 1.2
    diff -u -r1.2 endian.h
    --- include/machine/endian.h 6 Jan 2021 14:55:05 -0000 1.2
    +++ include/machine/endian.h 13 Jan 2021 16:23:19 -0000
    @@ -54,11 +54,6 @@
    #define __PDP_ENDIAN PDP_ENDIAN
    #define __BYTE_ORDER LITTLE_ENDIAN

    -#define __LITTLE_ENDIAN__ LITTLE_ENDIAN
    -#define __BIG_ENDIAN__ BIG_ENDIAN
    -#define __PDP_ENDIAN__ PDP_ENDIAN
    -#define __BYTE_ORDER__ LITTLE_ENDIAN
    -

    #include <sys/cdefs.h>


    Applied the patch above to cvs.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)