• [PATCH v3] dxe3gen: invoke ld/as via gcc

    From [via djgpp@delorie.com]" @21:1/5 to All on Sat Jan 28 23:09:30 2023
    Posting this in a new thread since the other became way too long.

    This applies to current cvs, and should address all raised concerns. I additionally noticed and fixed a small inconsistency in the -h text, as
    linker options are now wrapped via -Wl.


    diff --git a/src/dxe/dxe3gen.c b/src/dxe/dxe3gen.c
    index a61d1a1e..81b5d447 100644
    --- a/src/dxe/dxe3gen.c
    +++ b/src/dxe/dxe3gen.c
    @@ -170,15 +170,9 @@
    #ifndef DXE_CC
    #define DXE_CC "gcc"
    #endif
    -#ifndef DXE_AS
    -#define DXE_AS "as"
    -#endif
    #ifndef DXE_AR
    #define DXE_AR "ar"
    #endif
    -#ifndef DXE_LD
    -#define DXE_LD "ld"
    -#endif
    #ifndef DXE_SC
    #define DXE_SC "dxe.ld"
    #endif
    @@ -193,7 +187,7 @@
    #include "../../include/sys/dxe.h"
    #include "../../include/coff.h"

    -#define VERSION "1.0.4"
    +#define VERSION "1.0.5"

    #define TEMP_BASE "dxe_tmp" /* 7 chars, 1 char suffix */
    #define TEMP_O_FILE TEMP_BASE".o"
    @@ -204,7 +198,7 @@
    #define IS_SLASH(path) (((path) == '/') || ((path) == '\\'))
    #define IS_DIR_SEPARATOR(path) (IS_SLASH(path) || ((path) == ':'))

    -#define NUMBER_OF_LINKER_ARGS 10
    +#define NUMBER_OF_LINKER_ARGS 7
    #define NUMBER_OF_ADDITIONAL_LOADED_LIBS 0

    #define IS_VALID_CIE(id) ((id) == 0)
    @@ -314,9 +308,7 @@ static struct
    static char *libdir;
    /* build tools */
    static char *dxe
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 29 08:19:49 2023
    Date: Sat, 28 Jan 2023 23:09:30 +0100
    From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>

    Posting this in a new thread since the other became way too long.

    This applies to current cvs, and should address all raised concerns. I additionally noticed and fixed a small inconsistency in the -h text, as linker options are now wrapped via -Wl.

    Thanks. I have only one question:

    + new_argv[0] = dxe_cc;
    + new_argv[1] = "-nostdlib";
    + new_argv[2] = "-Wl,-X,-S,-r";
    + new_argv[3] = "-o";
    + new_argv[4] = TEMP_O_FILE;
    + new_argv[5] = "-T";
    + new_argv[6] = dxe_sc;

    Why do we need -nostdlib? It wasn't used before, AFAICT.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 29 10:50:37 2023
    + if (libdir)
    {
    - fprintf(stderr, "Error: neither DXE_LD_LIBRARY_PATH nor DJDIR are set
    in environment\n");
    - exit(1);
    + /* For compatibility with version 1.0.4 and earlier, also search
    + $DXE_LD_LIBRARY_PATH or $DJDIR/lib, if set. */
    + new_argv[new_argc++] = "-L";
    + new_argv[new_argc++] = libdir;

    How will this work with NUMBER_OF_LINKER_ARGS being 7?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Sun Jan 29 08:15:17 2023
    On 2023-01-29 07:19, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] wrote:
    Date: Sat, 28 Jan 2023 23:09:30 +0100
    From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>

    Posting this in a new thread since the other became way too long.

    This applies to current cvs, and should address all raised concerns. I
    additionally noticed and fixed a small inconsistency in the -h text, as
    linker options are now wrapped via -Wl.

    Thanks. I have only one question:

    + new_argv[0] = dxe_cc;
    + new_argv[1] = "-nostdlib";
    + new_argv[2] = "-Wl,-X,-S,-r";
    + new_argv[3] = "-o";
    + new_argv[4] = TEMP_O_FILE;
    + new_argv[5] = "-T";
    + new_argv[6] = dxe_sc;

    Why do we need -nostdlib? It wasn't used before, AFAICT.

    This prevents gcc from implicitly linking in any libraries (libc, libgcc and crt0.o), as it wants to do by default. It wasn't there before, since it's a gcc-specific option.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 29 09:54:03 2023
    Date: Sun, 29 Jan 2023 08:15:17 +0100
    From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>

    On 2023-01-29 07:19, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] wrote:
    Date: Sat, 28 Jan 2023 23:09:30 +0100
    From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>

    Posting this in a new thread since the other became way too long.

    This applies to current cvs, and should address all raised concerns. I
    additionally noticed and fixed a small inconsistency in the -h text, as
    linker options are now wrapped via -Wl.

    Thanks. I have only one question:

    + new_argv[0] = dxe_cc;
    + new_argv[1] = "-nostdlib";
    + new_argv[2] = "-Wl,-X,-S,-r";
    + new_argv[3] = "-o";
    + new_argv[4] = TEMP_O_FILE;
    + new_argv[5] = "-T";
    + new_argv[6] = dxe_sc;

    Why do we need -nostdlib? It wasn't used before, AFAICT.

    This prevents gcc from implicitly linking in any libraries (libc, libgcc and crt0.o), as it wants to do by default. It wasn't there before, since it's a gcc-specific option.

    Sorry, I missed the fact that your original patch also had this
    option.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 29 15:45:58 2023
    How about the following suggestion?

    Index: dxe3gen.c ===================================================================
    RCS file: /cvs/djgpp/djgpp/src/dxe/dxe3gen.c,v
    retrieving revision 1.27
    diff -u -p -r1.27 dxe3gen.c
    --- dxe3gen.c 28 Jan 2023 14:10:03 -0000 1.27
    +++ dxe3gen.c 29 Jan 2023 12:41:30 -0000
    @@ -19,6 +19,7 @@
    otherwise the exit code of GNU ld is returned
    */

    +#include <limits.h>
    #include <ctype.h>
    #include <stdio.h>
    #include <stdlib.h>
    @@ -204,7 +205,7 @@
    #define IS_SLASH(path) (((path) == '/') || ((path) == '\\'))
    #define IS_DIR_SEPARATOR(path) (IS_SLASH(path) || ((path) == ':'))

    -#define NUMBER_OF_LINKER_ARGS 10
    +#define NUMBER_OF_LINKER_ARGS 12
    #define NUMBER_OF_ADDITIONAL_LOADED_LIBS 0

    #define IS_VALID_CIE(id) ((id) == 0)
    @@ -465,6 +466,25 @@ static void process_env(void)
    }


    +static char libgcc_dir[PATH_MAX];
    +static void read_libgccdir(void)
    +{
    + char *ptr;
    + FILE *p;
    +
    + sprintf(libgcc_dir, "%s -print-libgcc-file-name", dxe_cc);
    + p = popen(libgcc_dir,"r");
    + memset(libgcc_dir, 0, sizeof(libgcc_dir));
    + if (!p) return;
    + while (fread(libgcc_dir, 1, sizeof(libgcc_dir), p) > 0) {
    + /**/
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 29 15:56:01 2023
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Sun, 29 Jan 2023 15:45:58 +0300

    How about the following suggestion?

    Is this really needed? IOW, can it really happen that the compiler
    fails to find libgcc unless explicitly told to look in the right
    directory?

    If this is indeed needed, I don't object, but please make sure the new
    function works also in the cross-compilation setup, and finds the
    correct version of libgcc.

    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 Sun Jan 29 17:07:45 2023
    On 1/29/23, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
    <djgpp@delorie.com>
    Date: Sun, 29 Jan 2023 15:45:58 +0300

    How about the following suggestion?

    Is this really needed? IOW, can it really happen that the compiler
    fails to find libgcc unless explicitly told to look in the right
    directory?

    gcc can, but ld can not: my suggested patch is not on top of JW's patch
    it is against cvs where we invoke ld, not gcc. (Remember that the whole
    purpose of JW's patch is that dxe3gen can find libgcc automatically w/o
    any user effort..)

    If this is indeed needed, I don't object, but please make sure the new function works also in the cross-compilation setup, and finds the
    correct version of libgcc.

    It does work in a cross- environment where I tested.

    Further updated patch below, which increments the version too.

    Index: dxe3gen.c ===================================================================
    RCS file: /cvs/djgpp/djgpp/src/dxe/dxe3gen.c,v
    retrieving revision 1.27
    diff -u -p -r1.27 dxe3gen.c
    --- dxe3gen.c 28 Jan 2023 14:10:03 -0000 1.27
    +++ dxe3gen.c 29 Jan 2023 13:01:40 -0000
    @@ -19,6 +19,7 @@
    otherwise the exit code of GNU ld is returned
    */

    +#include <limits.h>
    #include <ctype.h>
    #include <stdio.h>
    #include <stdlib.h>
    @@ -193,7 +194,7 @@
    #include "../../include/sys/dxe.h"
    #include "../../include/coff.h"

    -#define VERSION "1.0.4"
    +#define VERSION "1.0.5"

    #define TEMP_BASE "dxe_tmp" /* 7 chars, 1 char suffix */
    #define TEMP_O_FILE TEMP_BASE".o"
    @@ -204,7 +205,7 @@
    #define IS_SLASH(path) (((path) == '/') || ((path) == '\\'))
    #define IS_DIR_SEPARATOR(path) (IS_SLASH(path) || ((path) == ':'))

    -#define NUMBER_OF_LINKER_ARGS 10
    +#define NUMBER_OF_LINKER_ARGS 12
    #define NUMBER_OF_ADDITIONAL_LOADED_LIBS 0

    #define IS_VALID_CIE(id) ((id) == 0)
    @@ -465,6 +466,29 @@ static void process_env(void)
    }


    +#ifdef _WIN32
    +#define popen _popen
    +#define pclose _pclose
    +#endif
    +static char libgcc_dir[PAT
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 29 18:20:15 2023
    How about the following suggestion?

    Is this really needed? IOW, can it really happen that the compiler
    fails to find libgcc unless explicitly told to look in the right
    directory?

    gcc can, but ld can not: my suggested patch is not on top of JW's patch
    it is against cvs where we invoke ld, not gcc. (Remember that the whole
    purpose of JW's patch is that dxe3gen can find libgcc automatically w/o
    any user effort..)

    So it's an alternative patch?

    Yes

    If so, what do you suggest to do with
    libstdc++, which AFAIU was the original motivation for the change?

    Aren't all gcc-provided versioned libraries residing in the same dir?
    My patch just relies on that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 29 17:44:02 2023
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Sun, 29 Jan 2023 18:20:15 +0300

    How about the following suggestion?

    Is this really needed? IOW, can it really happen that the compiler
    fails to find libgcc unless explicitly told to look in the right
    directory?

    gcc can, but ld can not: my suggested patch is not on top of JW's patch
    it is against cvs where we invoke ld, not gcc. (Remember that the whole
    purpose of JW's patch is that dxe3gen can find libgcc automatically w/o
    any user effort..)

    So it's an alternative patch?

    Yes

    If so, what do you suggest to do with
    libstdc++, which AFAIU was the original motivation for the change?

    Aren't all gcc-provided versioned libraries residing in the same dir?
    My patch just relies on that.

    Maybe so, I simply don't know. So I think the code should have a
    comment to that effect.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 29 19:23:47 2023
    If so, what do you suggest to do with
    libstdc++, which AFAIU was the original motivation for the change?

    Aren't all gcc-provided versioned libraries residing in the same dir?
    My patch just relies on that.

    Maybe so, I simply don't know. So I think the code should have a
    comment to that effect.

    Updated patch inlined below:

    Comment added as suggested, documentation updated, and while loop
    reading from pipe removed and reduced to a single fread.

    Index: dxe3gen.c ===================================================================
    RCS file: /cvs/djgpp/djgpp/src/dxe/dxe3gen.c,v
    retrieving revision 1.27
    diff -u -p -r1.27 dxe3gen.c
    --- djgpp/src/dxe/dxe3gen.c 28 Jan 2023 14:10:03 -0000 1.27
    +++ djgpp/src/dxe/dxe3gen.c 29 Jan 2023 15:55:10 -0000
    @@ -19,6 +19,7 @@
    otherwise the exit code of GNU ld is returned
    */

    +#include <limits.h>
    #include <ctype.h>
    #include <stdio.h>
    #include <stdlib.h>
    @@ -193,7 +194,7 @@
    #include "../../include/sys/dxe.h"
    #include "../../include/coff.h"

    -#define VERSION "1.0.4"
    +#define VERSION "1.0.5"

    #define TEMP_BASE "dxe_tmp" /* 7 chars, 1 char suffix */
    #define TEMP_O_FILE TEMP_BASE".o"
    @@ -204,7 +205,7 @@
    #define IS_SLASH(path) (((path) == '/') || ((path) == '\\'))
    #define IS_DIR_SEPARATOR(path) (IS_SLASH(path) || ((path) == ':'))

    -#define NUMBER_OF_LINKER_ARGS 10
    +#define NUMBER_OF_LINKER_ARGS 12
    #define NUMBER_OF_ADDITIONAL_LOADED_LIBS 0

    #define IS_VALID_CIE(id) ((id) == 0)
    @@ -465,6 +466,37 @@ static void process_env(void)
    }


    +/* Desc: Read libgcc directory from the compiler so that ld can find -lg
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Sun Jan 29 19:35:15 2023
    On 2023-01-29 16:20, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
    How about the following suggestion?

    Is this really needed? IOW, can it really happen that the compiler
    fails to find libgcc unless explicitly told to look in the right
    directory?

    gcc can, but ld can not: my suggested patch is not on top of JW's patch
    it is against cvs where we invoke ld, not gcc. (Remember that the whole
    purpose of JW's patch is that dxe3gen can find libgcc automatically w/o
    any user effort..)

    So it's an alternative patch?

    Yes

    If so, what do you suggest to do with
    libstdc++, which AFAIU was the original motivation for the change?

    Aren't all gcc-provided versioned libraries residing in the same dir?
    My patch just relies on that.

    It is probably possible to configure different directories for libstdc++ and libgcc. The native gpp*b.zip packages on ftp seem to do that.

    But another benefit of using gcc to invoke the linker, is that additional default library paths can be added via the specs file. For example, with my toolchain packages for Debian, linking via gcc will search:

    /usr/i386-pc-msdosdjgpp/local/lib (libraries compiled by user) /usr/lib/gcc/i386-pc-msdosdjgpp/x.x.x (gcc / libstdc++ libraries) /usr/i386-pc-msdosdjgpp/lib (libraries installed via package manager)

    And of course, users will no longer need to set any environment vars to run dxe3gen. It will just work "out of the box". That wasn't the initial goal, but I think it's a welcome side-effect.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Mon Jan 30 00:17:02 2023
    If so, what do you suggest to do with
    libstdc++, which AFAIU was the original motivation for the change?

    Aren't all gcc-provided versioned libraries residing in the same dir?
    My patch just relies on that.

    It is probably possible to configure different directories for libstdc++
    and libgcc. The native gpp*b.zip packages on ftp seem to do that.

    I took gcc1030b.zip and its companion gpp1030b.zip as an example: libgcc
    is under <base>/lib/gcc/djgpp/10, whereas libssp and libstdc++ are under <base>/lib, and my version handles both.

    But another benefit of using gcc to invoke the linker, is that additional default library paths can be added via the specs file. For example, with
    my toolchain packages for Debian, linking via gcc will search:

    /usr/i386-pc-msdosdjgpp/local/lib (libraries compiled by user) /usr/lib/gcc/i386-pc-msdosdjgpp/x.x.x (gcc / libstdc++ libraries) /usr/i386-pc-msdosdjgpp/lib (libraries installed via package manager)

    Yes, that's an advantage.

    And of course, users will no longer need to set any environment vars to
    run dxe3gen. It will just work "out of the box". That wasn't the initial goal, but I think it's a welcome side-effect.

    Yes, that's another advantage.

    The only downside to your patch is that older gcc versions have a problem handling -T on their command line, which is why I had gone back. I don't
    have a solution for that, buit I honestly haven't tried very much.

    Eli, DJ: What do you guys think?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Sun Jan 29 23:14:50 2023
    On 2023-01-29 22:17, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
    If so, what do you suggest to do with
    libstdc++, which AFAIU was the original motivation for the change?

    Aren't all gcc-provided versioned libraries residing in the same dir?
    My patch just relies on that.

    It is probably possible to configure different directories for libstdc++
    and libgcc. The native gpp*b.zip packages on ftp seem to do that.

    I took gcc1030b.zip and its companion gpp1030b.zip as an example: libgcc
    is under <base>/lib/gcc/djgpp/10, whereas libssp and libstdc++ are under <base>/lib, and my version handles both.

    But another benefit of using gcc to invoke the linker, is that additional
    default library paths can be added via the specs file. For example, with
    my toolchain packages for Debian, linking via gcc will search:

    /usr/i386-pc-msdosdjgpp/local/lib (libraries compiled by user)
    /usr/lib/gcc/i386-pc-msdosdjgpp/x.x.x (gcc / libstdc++ libraries)
    /usr/i386-pc-msdosdjgpp/lib (libraries installed via package manager)

    Yes, that's an advantage.

    And of course, users will no longer need to set any environment vars to
    run dxe3gen. It will just work "out of the box". That wasn't the initial >> goal, but I think it's a welcome side-effect.

    Yes, that's another advantage.

    The only downside to your patch is that older gcc versions have a problem handling -T on their command line, which is why I had gone back. I don't have a solution for that, buit I honestly haven't tried very much.

    Eli, DJ: What do you guys think?

    Consider also: gcc 2.95 is in the deleted/ directory on ftp. To me, that would indicate that it's no longer supported, and that code in cvs does not necessarily need to be compatible with it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Mon Jan 30 01:50:08 2023
    + new_argv[new_argc++] = "-L";
    + new_argv[new_argc++] = libdir;

    How will this work with NUMBER_OF_LINKER_ARGS being 7?

    Forgot to reply to your question, sorry.

    In main(), additional space for 2 more arguments is allocated
    if libdir is set.

    Ah, that would be this new line and its use in next to it
    libdir_argc = libdir ? 2 : 0;

    Missed that one, sorry.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Sun Jan 29 23:32:34 2023
    On 2023-01-29 08:50, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
    + if (libdir)
    {
    - fprintf(stderr, "Error: neither DXE_LD_LIBRARY_PATH nor DJDIR are set >> in environment\n");
    - exit(1);
    + /* For compatibility with version 1.0.4 and earlier, also search
    + $DXE_LD_LIBRARY_PATH or $DJDIR/lib, if set. */
    + new_argv[new_argc++] = "-L";
    + new_argv[new_argc++] = libdir;

    How will this work with NUMBER_OF_LINKER_ARGS being 7?

    Forgot to reply to your question, sorry.

    In main(), additional space for 2 more arguments is allocated if libdir is set.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com on Mon Jan 30 17:17:04 2023
    On 1/30/23, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:

    The only downside to your patch is that older gcc versions have a
    problem handling -T on their command line, which is why I had gone
    back. I don't have a solution for that, buit I honestly haven't
    tried very much.

    Eli, DJ: What do you guys think?

    How serious is the issue with the linker script? Is that a problem
    only for GCC 2.95?

    As I had said, I only tested with gcc-3.4.6 (cross- under i686-linux)
    and 2.95 (native under dosbox). Gcc versions 4.x and newer _should_
    be OK. Don't know how gcc 3.0.x, 3.1.x, 3.2.x, and 3.3.x behave.

    EDIT: I now tested 3.3.6 and 8.2.0, both cross- under i686-linux, and
    they both work OK with JW's patch. I now do not know the behavior of
    only gcc 3.0.x, 3.1.x and 3.2.x, and possibly they are not worth much
    to worry about.

    If so, I'm okay with using GCC and documenting
    that 2.95 is no longer supported for this purpose.

    OK then, no objections from me. Feel free to apply the patch.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to Ozkan Sezer on Tue Jan 31 23:17:13 2023
    On 1/30/23, Ozkan Sezer <sezeroz@gmail.com> wrote:
    On 1/30/23, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:

    The only downside to your patch is that older gcc versions have a
    problem handling -T on their command line, which is why I had gone
    back. I don't have a solution for that, buit I honestly haven't
    tried very much.

    Eli, DJ: What do you guys think?

    How serious is the issue with the linker script? Is that a problem
    only for GCC 2.95?

    As I had said, I only tested with gcc-3.4.6 (cross- under i686-linux)
    and 2.95 (native under dosbox). Gcc versions 4.x and newer _should_
    be OK. Don't know how gcc 3.0.x, 3.1.x, 3.2.x, and 3.3.x behave.

    EDIT: I now tested 3.3.6 and 8.2.0, both cross- under i686-linux, and
    they both work OK with JW's patch. I now do not know the behavior of
    only gcc 3.0.x, 3.1.x and 3.2.x, and possibly they are not worth much
    to worry about.

    If so, I'm okay with using GCC and documenting
    that 2.95 is no longer supported for this purpose.

    OK then, no objections from me. Feel free to apply the patch.

    Is JW's patch OK'ed? If it is, will you apply it or should I?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Wed Feb 1 05:29:16 2023
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Tue, 31 Jan 2023 23:17:13 +0300

    If so, I'm okay with using GCC and documenting
    that 2.95 is no longer supported for this purpose.

    OK then, no objections from me. Feel free to apply the patch.

    Is JW's patch OK'ed? If it is, will you apply it or should I?

    Please apply, and 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 Wed Feb 1 10:25:16 2023
    On 2/1/23, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
    <djgpp@delorie.com>
    Date: Tue, 31 Jan 2023 23:17:13 +0300

    If so, I'm okay with using GCC and documenting
    that 2.95 is no longer supported for this purpose.

    OK then, no objections from me. Feel free to apply the patch.

    Is JW's patch OK'ed? If it is, will you apply it or should I?

    Please apply, and thanks.

    JW's patch is in the CVS now, after a re-diff and a minor edit.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Wed Feb 1 19:42:56 2023
    On 2023-02-01 08:25, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
    On 2/1/23, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
    <djgpp@delorie.com>
    Date: Tue, 31 Jan 2023 23:17:13 +0300

    If so, I'm okay with using GCC and documenting
    that 2.95 is no longer supported for this purpose.

    OK then, no objections from me. Feel free to apply the patch.

    Is JW's patch OK'ed? If it is, will you apply it or should I?

    Please apply, and thanks.

    JW's patch is in the CVS now, after a re-diff and a minor edit.

    Nice, thanks! I see you cleaned up the allocation in main() a bit, this is definitely a nicer solution.

    Now, if anyone here could take the time to also look into the other two patches I sent, I would highly appreciate it :)

    --- 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 Feb 2 00:05:46 2023
    On 2/1/23, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
    <djgpp@delorie.com>
    Date: Wed, 1 Feb 2023 23:22:28 +0300

    (I messed up the commit message a bit, and forgot adding your
    name as the patch author, though..)

    This is CVS, not Git, so commit messages can be corrected.

    How?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Wed Feb 1 23:22:28 2023
    JW's patch is in the CVS now, after a re-diff and a minor edit.

    Nice, thanks! I see you cleaned up the allocation in main() a bit, this is definitely a nicer solution.

    You're welcome

    (I messed up the commit message a bit, and forgot adding your
    name as the patch author, though..)

    --- 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 Feb 2 11:25:59 2023
    On 2/2/23, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
    <djgpp@delorie.com>
    Date: Thu, 2 Feb 2023 00:05:46 +0300

    (I messed up the commit message a bit, and forgot adding your
    name as the patch author, though..)

    This is CVS, not Git, so commit messages can be corrected.

    How?

    cvs -z3 -d URL admin -mREVISION:MESSAGE FILE

    where REVISION is the last revision number of FILE in the usual x.y.z numerical format, and MESSAGE is the (possibly quoted) commit log
    message to replace the old one. URL is the URL you use to access
    DJGPP repository.


    Got it. And done. Thanks.

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