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.
+ 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;
+ 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;
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.
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.
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?
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.
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?
If so, what do you suggest to do with
libstdc++, which AFAIU was the original motivation for the change?
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.
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.
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.
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.
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?
+ 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.
+ 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?
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?
If so, I'm okay with using GCC and documenting
that 2.95 is no longer supported for this purpose.
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.
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?
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.
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.
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.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 351 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:23:19 |
| Calls: | 7,634 |
| Files: | 12,796 |
| Messages: | 5,689,020 |