Hello,
I'm working on a C++ project with DXE3 and found it cannot resolve throw_length_error() on dlopen(). Upon inspection, this is stemming
from my use of std::vector in some places. Is there a way to resolve it
with DXE_EXPORT() without having to redo the code to not use
std::vector? Right now I'm just getting the mangled name for it, '`__ZSt20__throw_length_errorPKc''
On 1/22/23, Frank Sapone (emoaddict15@gmail.com) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
Hello,Do you not link to libstdc++ (and libgcc) ?
I'm working on a C++ project with DXE3 and found it cannot resolve
throw_length_error() on dlopen(). Upon inspection, this is stemming
from my use of std::vector in some places. Is there a way to resolve it
with DXE_EXPORT() without having to redo the code to not use
std::vector? Right now I'm just getting the mangled name for it,
'`__ZSt20__throw_length_errorPKc''
If you really do and it still happens, then I don't know.
Is the project open?
By link, you mean for dxe3gen?
If yes, then I tried that.
And no, the project is not open unfortunately.
Syntax for building the DXE: 'dxe3gen -V -U -E _dll_Entry -lstdc++ -lgcc
<my objs> <my dxe>'
However, I had to copy libstdc++.a and libgcc.a from C:\djgpp\lib\gcc\i586-pc-msdosdjgpp\4.9.4 to
C:\djgpp\i586-pc-msdosdjgpp\lib
which I suspect is incorrect
Maybe. I'll give that a try tonight. The only difference from what
I'm doing now is I'm doing DXE_LIBS /before/ the OBJECTS.
However, I had to copy libstdc++.a and libgcc.a from
C:\djgpp\lib\gcc\i586-pc-msdosdjgpp\4.9.4 to
C:\djgpp\i586-pc-msdosdjgpp\lib
Sounds correct from what you write,
Having to copy the lib? I dont remember doing that,
Just seems wrong to have to copy
important libs like that?
And no, the project is not open unfortunately.
Is this dk ?
Syntax for building the DXE: 'dxe3gen -V -U -E _dll_Entry -lstdc++ -lgcc <my objs> <my dxe>'
In sin, we used to do
$(DXE3GEN) -V -U -E _GetGameAPI $(OBJECTS) $(DXE_LIBS) -o gamex86.dxe
And it used to work. Maybe the order is important?
Can't remember details.
However, I had to copy libstdc++.a and libgcc.a from C:\djgpp\lib\gcc\i586-pc-msdosdjgpp\4.9.4 to C:\djgpp\i586-pc-msdosdjgpp\lib
Sounds correct from what you write,
<br></div><div>PS Apologies in advance for bad formatting, on a phone today.</div>
Maybe. I'll give that a try tonight. The only difference from whatI'd like to hear the result. Remember that
I'm doing now is I'm doing DXE_LIBS /before/ the OBJECTS.
dxe3gen --show-unres xxx.dxe
will output the missing symbols in the dxe.
Just seems wrong to have to copyThat's a shortcoming of dxe3gen with gcc-provided libraries,
important libs like that?
needs to be addressed but no one cared (or no one reported
the issue probably.)
Maybe. I'll give that a try tonight. The only difference from whatI'd like to hear the result. Remember that
I'm doing now is I'm doing DXE_LIBS /before/ the OBJECTS.
dxe3gen --show-unres xxx.dxe
will output the missing symbols in the dxe.
Yes, this is exactly the problem. So, apparently, you must do
-l <your interesting libs> AFTER $(OBJECTS) otherwise it does not
work.
Just seems wrong to have to copyThat's a shortcoming of dxe3gen with gcc-provided libraries,
important libs like that?
needs to be addressed but no one cared (or no one reported
the issue probably.)
Any possibility of you being able to generate a patch or can we get
it into documentation?
The thing is, dxe3gen invokes ld, not gcc. gcc is a front-end to ld
and handles any such ugliness behind the scene and doing the same for
dxe3gen might be a real pain.
On 2023-01-23 05:00, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:It is should be easy:
The thing is, dxe3gen invokes ld, not gcc. gcc is a front-end to ldI think the tricky part is to prevent gcc from invoking stubify on the resulting object file. Otherwise, it doesn't look too difficult. Just replace
and handles any such ugliness behind the scene and doing the same for
dxe3gen might be a real pain.
param sequences such as "-T" "dxe.ld" with "-Wl,-T,dxe.ld". The same can be done for DXE_AS.
On 1/23/23 20:06, J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com] wrote:
On 2023-01-23 05:00, Ozkan Sezer (sezeroz@gmail.com) [viaIt is should be easy:
djgpp@delorie.com] wrote:
The thing is, dxe3gen invokes ld, not gcc. gcc is a front-end to ldI think the tricky part is to prevent gcc from invoking stubify on the
and handles any such ugliness behind the scene and doing the same for
dxe3gen might be a real pain.
resulting object file. Otherwise, it doesn't look too difficult. Just
replace
param sequences such as "-T" "dxe.ld" with "-Wl,-T,dxe.ld". The same can
be
done for DXE_AS.
1) dump GCC specs (gcc -dumpspecs >some_file
2) delete next line after line containing '*post_link:'
3) use that file in -T option
Andris
On 1/25/23, Andris Pavenis (andris.pavenis@iki.fi) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
On 1/23/23 20:06, J.W. Jagersma (jwjagersma@gmail.com) [via
djgpp@delorie.com] wrote:
On 2023-01-23 05:00, Ozkan Sezer (sezeroz@gmail.com) [viaIt is should be easy:
djgpp@delorie.com] wrote:
The thing is, dxe3gen invokes ld, not gcc. gcc is a front-end to ldI think the tricky part is to prevent gcc from invoking stubify on the
and handles any such ugliness behind the scene and doing the same for
dxe3gen might be a real pain.
resulting object file. Otherwise, it doesn't look too difficult. Just
replace
param sequences such as "-T" "dxe.ld" with "-Wl,-T,dxe.ld". The same can >>> be
done for DXE_AS.
1) dump GCC specs (gcc -dumpspecs >some_file
2) delete next line after line containing '*post_link:'
3) use that file in -T option
Andris
No '*post_link:' in my gcc's dumpspecs (gcc-3.4.6, cross- from linux.)
On 2023-01-25 20:25, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
On 1/25/23, Andris Pavenis (andris.pavenis@iki.fi) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
On 1/23/23 20:06, J.W. Jagersma (jwjagersma@gmail.com) [via
djgpp@delorie.com] wrote:
On 2023-01-23 05:00, Ozkan Sezer (sezeroz@gmail.com) [viaIt is should be easy:
djgpp@delorie.com] wrote:
The thing is, dxe3gen invokes ld, not gcc. gcc is a front-end to ld >>>>> and handles any such ugliness behind the scene and doing the same for >>>>> dxe3gen might be a real pain.I think the tricky part is to prevent gcc from invoking stubify on the >>>> resulting object file. Otherwise, it doesn't look too difficult. Just >>>> replace
param sequences such as "-T" "dxe.ld" with "-Wl,-T,dxe.ld". The same can >>>> be
done for DXE_AS.
1) dump GCC specs (gcc -dumpspecs >some_file
2) delete next line after line containing '*post_link:'
3) use that file in -T option
Andris
No '*post_link:' in my gcc's dumpspecs (gcc-3.4.6, cross- from linux.)
I think Andris added the post_link step somewhere in 4.x, earlier versions do not call stubify. So that doesn't require any special code.
Just seems wrong to have to copyThat's a shortcoming of dxe3gen with gcc-provided libraries,
important libs like that?
needs to be addressed but no one cared (or no one reported
the issue probably.)
Any possibility of you being able to generate a patch or can we get
it into documentation?
The thing is, dxe3gen invokes ld, not gcc. gcc is a front-end to ld
and handles any such ugliness behind the scene and doing the same for
dxe3gen might be a real pain.
If someone other than me can generate solution for this, or at least
some documentation, it'd be nice.
On 2023-01-23 05:00, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
Just seems wrong to have to copyThat's a shortcoming of dxe3gen with gcc-provided libraries,
important libs like that?
needs to be addressed but no one cared (or no one reported
the issue probably.)
Any possibility of you being able to generate a patch or can we get
it into documentation?
The thing is, dxe3gen invokes ld, not gcc. gcc is a front-end to ld
and handles any such ugliness behind the scene and doing the same for
dxe3gen might be a real pain.
If someone other than me can generate solution for this, or at least
some documentation, it'd be nice.
Seems stubify does not delete/overwrite the input file if the file
extension
is something other than .exe, so calling stubify isn't so disastrous.
I have a preliminary patch, attached, untested.
On 1/26/23, J.W. Jagersma (jwjagersma@gmail.com) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
On 2023-01-23 05:00, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] >> wrote:
Just seems wrong to have to copyThat's a shortcoming of dxe3gen with gcc-provided libraries,
important libs like that?
needs to be addressed but no one cared (or no one reported
the issue probably.)
Any possibility of you being able to generate a patch or can we get
it into documentation?
The thing is, dxe3gen invokes ld, not gcc. gcc is a front-end to ld
and handles any such ugliness behind the scene and doing the same for
dxe3gen might be a real pain.
If someone other than me can generate solution for this, or at least
some documentation, it'd be nice.
Seems stubify does not delete/overwrite the input file if the file
extension
is something other than .exe, so calling stubify isn't so disastrous.
I have a preliminary patch, attached, untested.
So, you invoke gcc instead of ld,
- removal of -X: O-OK, default anyway.
- removal of -S: Are you really sure?
- removal of -r: Don't think that it'd work.
- removal of assembler for import lib
generation: Don't think that it'd work.
Just tried the patched binary with a dxe build project, it fails
as expected:
./dxe3gen -o sndpci.dxe -E _AU_ -U au.o ac97_def.o dpmi_c.o mdma.o
pcibios.o sc_cmi.o sc_e1371.o sc_ich.o sc_inthd.o sc_sbl24.o
sc_sbliv.o sc_sbxfi.o sc_via82.o tim.o udivdi3.o
dxe_tmp.o: linker output file has more than one section
Getting multiple input sections sounds like some problem with the linker script.
Do you have an open-source project for me to test on? I'll admit that I've never used DXE libraries before...
- removal of -X: O-OK, default anyway.
- removal of -S: Are you really sure?
- removal of -r: Don't think that it'd work.
Those are in ld_args now (-Wl,-X,-S,-r,-T,dxe.ld), gcc splits it at
the commas.
- removal of assembler for import lib
generation: Don't think that it'd work.
The assembler is invoked via dxe_cc (gcc -c) instead.
Getting multiple input sections sounds like some problem with the
linker script. Do you have an open-source project for me to test on?
I'll admit that I've never used DXE libraries before...
Getting multiple input sections sounds like some problem with the linker script.
Do you have an open-source project for me to test on? I'll admit that I've >> never used DXE libraries before...
Q2DOS is GPL2: https://bitbucket.org/neozeed/q2dos
Frank
Getting multiple input sections sounds like some problem with the
linker script. Do you have an open-source project for me to test on?
I'll admit that I've never used DXE libraries before...
Here is a tiny one: http://uhexen2.sourceforge.net/tmp/libau.tar.gz
cd into src, and adjust Makefile.dj and cross_build.sh scripts as you
need. If you want to test linking with -lgcc, remove 'udivdi3.o' from
the objects and add -lgcc
Thanks. It builds fine for me with the patched dxe3gen, no warnings,
both with and without -lgcc.
Well, it does not for me, which _is_ a problem. My toolchain is based on gcc-3.4.6 and binutils-2.26.1.
- removal of -X: O-OK, default anyway.
- removal of -S: Are you really sure?
- removal of -r: Don't think that it'd work.
Those are in ld_args now (-Wl,-X,-S,-r,-T,dxe.ld), gcc splits it at
the commas.
OK, missed that part,
- removal of assembler for import lib
generation: Don't think that it'd work.
The assembler is invoked via dxe_cc (gcc -c) instead.
OK,
Getting multiple input sections sounds like some problem with the
linker script. Do you have an open-source project for me to test on?
I'll admit that I've never used DXE libraries before...
Here is a tiny one: http://uhexen2.sourceforge.net/tmp/libau.tar.gz
cd into src, and adjust Makefile.dj and cross_build.sh scripts as you
need. If you want to test linking with -lgcc, remove 'udivdi3.o' from
the objects and add -lgcc
Getting multiple input sections sounds like some problem with the
linker script. Do you have an open-source project for me to test on?
I'll admit that I've never used DXE libraries before...
Here is a tiny one: http://uhexen2.sourceforge.net/tmp/libau.tar.gz
cd into src, and adjust Makefile.dj and cross_build.sh scripts as you
need. If you want to test linking with -lgcc, remove 'udivdi3.o' from
the objects and add -lgcc
Thanks. It builds fine for me with the patched dxe3gen, no warnings,
both with and without -lgcc.
Thanks. It builds fine for me with the patched dxe3gen, no warnings,
both with and without -lgcc.
Well, it does not for me, which _is_ a problem. My toolchain is based on >>> gcc-3.4.6 and binutils-2.26.1.
If you comment out the line with "remove(TEMP_O_FILE)", then run
dxe3gen again, what does "objdump -h dxe_tmp.o" (or -x) show?
Here you go:
h0.txt and x0.txt are outputs of -h and -x before the patch.
h1.txt and x1.txt are outputs of -h and -x after the patch.
Yes, this one does work, and yields an identical dxe.
DJ, Eli: I'd like to apply this patch. Any objections?
"Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
<djgpp@delorie.com> writes:
Yes, this one does work, and yields an identical dxe.
DJ, Eli: I'd like to apply this patch. Any objections?
No objections from me.
Thanks. It builds fine for me with the patched dxe3gen, no warnings,
both with and without -lgcc.
Well, it does not for me, which _is_ a problem. My toolchain is based on >>> gcc-3.4.6 and binutils-2.26.1.
If you comment out the line with "remove(TEMP_O_FILE)", then run
dxe3gen again, what does "objdump -h dxe_tmp.o" (or -x) show?
Here you go:
h0.txt and x0.txt are outputs of -h and -x before the patch.
h1.txt and x1.txt are outputs of -h and -x after the patch.
On 2023-01-27 19:10, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
Thanks. It builds fine for me with the patched dxe3gen, no warnings, >>>>> both with and without -lgcc.
Well, it does not for me, which _is_ a problem. My toolchain is based
on
gcc-3.4.6 and binutils-2.26.1.
If you comment out the line with "remove(TEMP_O_FILE)", then run
dxe3gen again, what does "objdump -h dxe_tmp.o" (or -x) show?
Here you go:
h0.txt and x0.txt are outputs of -h and -x before the patch.
h1.txt and x1.txt are outputs of -h and -x after the patch.
Ah, I see now. gcc 3 inserts the wrong linker script.
From the specs file you posted earlier:
%{!T*:-Tdjgpp-x.djl} %{T*}
This means, if no -T option is given, it uses -Tdjgpp-x.djl. Weirdly the
-T
option is not documented for gcc 3.4.6, that is why I assumed it had to be wrapped via -Wl.
New patch attached, this should work then.
DJ, Eli: I'd like to apply this patch. Any objections?
I won't fight its inclusion, but I wonder whether all of the aspects
of this patch have been considered. I'm worried by the changes in
behavior this patch brings. At least the following stand out:
the code will no longer heed DXE_LD_LIBRARY_PATH and DJDIR
makefile.dxe uses "?=", which AFAICT we never used in the DJGPP
build tree
What if someone wants to use those
environment variables to tweak the build of a DXE?
Also, this comment no longer describes what the code does, after the
change:
/* Allright, now run the assembler on the resulting file */
- sprintf(cmdbuf, "%s -o %s %s", dxe_as, TEMP_O_FILE, TEMP_S_FILE);
+ sprintf(cmdbuf, "%s -c -o %s %s", dxe_cc, TEMP_O_FILE, TEMP_S_FILE);
If you aren't going to wait for me to answer your questions, why ask
me?
. the code will no longer heed DXE_LD_LIBRARY_PATH and DJDIR
In the vast majority of cases those would point to the global lib
directory.
That is no longer necessary, gcc will know where to look.
In case someone used DXE_LD_LIBRARY_PATH to point to something
else, that seems like a strange configuration, was that ever intended to
be supported?
I also had yet to update the manual for the v2 patch:
Also, I suppose the version number should be bumped.
I meant in dxegen.txi, line 68. It should read:
DXE_SC: Path to linker script name. If not set, defaults to dxe.ld.
-Passed internally to the linker, like 'gcc -Wl,-T,dxe.ld'
+Passed internally to the linker, like 'gcc -T dxe.ld'
@end example
Also, I suppose the version number should be bumped.
djgpp-2.05 had version 1.0.3. The cvs 2.0.6 version is now at 1.0.4
But people have been compiling dxe3gen from cvs for a while,
so they will
already have a v1.0.4. I think it's a good idea to signal that this
version is different.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Fri, 27 Jan 2023 22:23:40 +0300
On 1/27/23, J.W. Jagersma (jwjagersma@gmail.com) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
On 2023-01-27 19:10, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]
wrote:
Thanks. It builds fine for me with the patched dxe3gen, no warnings, >>>>>>> both with and without -lgcc.
Well, it does not for me, which _is_ a problem. My toolchain is based >>>>>> on
gcc-3.4.6 and binutils-2.26.1.
If you comment out the line with "remove(TEMP_O_FILE)", then run
dxe3gen again, what does "objdump -h dxe_tmp.o" (or -x) show?
Here you go:
h0.txt and x0.txt are outputs of -h and -x before the patch.
h1.txt and x1.txt are outputs of -h and -x after the patch.
Ah, I see now. gcc 3 inserts the wrong linker script.
From the specs file you posted earlier:
%{!T*:-Tdjgpp-x.djl} %{T*}
This means, if no -T option is given, it uses -Tdjgpp-x.djl. Weirdly the >>> -T
option is not documented for gcc 3.4.6, that is why I assumed it had to be >>> wrapped via -Wl.
New patch attached, this should work then.
Yes, this one does work, and yields an identical dxe.
DJ, Eli: I'd like to apply this patch. Any objections?
I won't fight its inclusion, but I wonder whether all of the aspects
of this patch have been considered. I'm worried by the changes in
behavior this patch brings. At least the following stand out:
. the code will no longer heed DXE_LD_LIBRARY_PATH and DJDIR
. makefile.dxe uses "?=", which AFAICT we never used in the DJGPP
build tree
Are these changes justified? What if someone wants to use those
environment variables to tweak the build of a DXE?
Also, this comment no longer describes what the code does, after the
change:
/* Allright, now run the assembler on the resulting file */
- sprintf(cmdbuf, "%s -o %s %s", dxe_as, TEMP_O_FILE, TEMP_S_FILE);
+ sprintf(cmdbuf, "%s -c -o %s %s", dxe_cc, TEMP_O_FILE, TEMP_S_FILE);
DXE_SC: Path to linker script name. If not set, defaults to dxe.ld.
-Passed internally to ld, like 'ld -T dxe.ld'
+Passed internally to the linker, like 'gcc -Wl,-T,dxe.ld'
@end example
. the code will no longer heed DXE_LD_LIBRARY_PATH and DJDIR
In the vast majority of cases those would point to the global lib
directory.
That is no longer necessary, gcc will know where to look.
In case someone used DXE_LD_LIBRARY_PATH to point to something
else, that seems like a strange configuration, was that ever intended to
be supported?
That one was supposed to let ld know where the library dir is.
If anyone else actually used it for something else, well, as I said,
they can always use -L/some/path -lfoo as they always could.
I also had yet to update the manual for the v2 patch:
I already updated the changelog, if that's what you mean.
Also, I suppose the version number should be bumped.
djgpp-2.05 had version 1.0.3. The cvs 2.0.6 version is now at 1.0.4
I meant in dxegen.txi, line 68. It should read:
DXE_SC: Path to linker script name. If not set, defaults to dxe.ld.
-Passed internally to the linker, like 'gcc -Wl,-T,dxe.ld'
+Passed internally to the linker, like 'gcc -T dxe.ld'
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Fri, 27 Jan 2023 23:00:28 +0300
Cc: djgpp@delorie.com
On 1/27/23, DJ Delorie <dj@delorie.com> wrote:
"Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com> writes:
Yes, this one does work, and yields an identical dxe.
DJ, Eli: I'd like to apply this patch. Any objections?
No objections from me.
Patch now applied to cvs. Thanks.
On 1/28/23, Ozkan Sezer <sezeroz@gmail.com> wrote:
I meant in dxegen.txi, line 68. It should read:
DXE_SC: Path to linker script name. If not set, defaults to dxe.ld.
-Passed internally to the linker, like 'gcc -Wl,-T,dxe.ld'
+Passed internally to the linker, like 'gcc -T dxe.ld'
One downside of the new version is that it does nıt seem to work with gcc2.95 as tested under dosbox -- the -T dxe.ld switches doesn't seem
to work and it spits the same multiple sections error.
Don't know whether we actually expect dxe3gen to work with gcc2.95 is
another matter: Should we care?
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Fri, 27 Jan 2023 22:23:40 +0300
On 1/27/23, J.W. Jagersma (jwjagersma@gmail.com) [via
djgpp@delorie.com] <djgpp@delorie.com> wrote:
On 2023-01-27 19:10, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]
wrote:
Thanks. It builds fine for me with the patched dxe3gen, no warnings, >>>>> both with and without -lgcc.
Well, it does not for me, which _is_ a problem. My toolchain is based >>>> on
gcc-3.4.6 and binutils-2.26.1.
If you comment out the line with "remove(TEMP_O_FILE)", then run
dxe3gen again, what does "objdump -h dxe_tmp.o" (or -x) show?
Here you go:
h0.txt and x0.txt are outputs of -h and -x before the patch.
h1.txt and x1.txt are outputs of -h and -x after the patch.
Ah, I see now. gcc 3 inserts the wrong linker script.
From the specs file you posted earlier:
%{!T*:-Tdjgpp-x.djl} %{T*}
This means, if no -T option is given, it uses -Tdjgpp-x.djl. Weirdly the -T
option is not documented for gcc 3.4.6, that is why I assumed it had to be wrapped via -Wl.
New patch attached, this should work then.
Yes, this one does work, and yields an identical dxe.
DJ, Eli: I'd like to apply this patch. Any objections?
/* Allright, now run the assembler on the resulting file */
- sprintf(cmdbuf, "%s -o %s %s", dxe_as, TEMP_O_FILE, TEMP_S_FILE);
+ sprintf(cmdbuf, "%s -c -o %s %s", dxe_cc, TEMP_O_FILE, TEMP_S_FILE);
Date: Fri, 27 Jan 2023 21:53:48 +0100
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
. the code will no longer heed DXE_LD_LIBRARY_PATH and DJDIR
In the vast majority of cases those would point to the global lib directory. That is no longer necessary, gcc will know where to look.
In case someone used DXE_LD_LIBRARY_PATH to point to something else, that seems
like a strange configuration, was that ever intended to be supported?
. makefile.dxe uses "?=", which AFAICT we never used in the DJGPP
build tree
I wasn't aware that this is modern / non-standard (is it though?). But this makefile is only used for quick cross-compiling without configuring/building the whole source tree, so presumably no old versions of GNU Make will ever see
it.
This change is not directly related to the rest of the patch. But some people (me) who use i386-pc-msdosdjgpp might want some method to configure the cross-prefix.
Also, this comment no longer describes what the code does, after the change:
/* Allright, now run the assembler on the resulting file */
- sprintf(cmdbuf, "%s -o %s %s", dxe_as, TEMP_O_FILE, TEMP_S_FILE);
+ sprintf(cmdbuf, "%s -c -o %s %s", dxe_cc, TEMP_O_FILE, TEMP_S_FILE);
It does run the assembler, just indirectly.
I also had yet to update the manual for the v2 patch:
DXE_SC: Path to linker script name. If not set, defaults to dxe.ld. -Passed internally to ld, like 'ld -T dxe.ld'
+Passed internally to the linker, like 'gcc -Wl,-T,dxe.ld'
@end example
This line is now somewhat inconsistent with the code. Also, I suppose the version number should be bumped.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Sat, 28 Jan 2023 00:58:19 +0300
One downside of the new version is that it does nıt seem to work with gcc2.95 as tested under dosbox -- the -T dxe.ld switches doesn't seem
to work and it spits the same multiple sections error.
Don't know whether we actually expect dxe3gen to work with gcc2.95 is
another matter: Should we care?
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Sat, 28 Jan 2023 00:03:33 +0300
. the code will no longer heed DXE_LD_LIBRARY_PATH and DJDIR
In the vast majority of cases those would point to the global lib directory.
That is no longer necessary, gcc will know where to look.
In case someone used DXE_LD_LIBRARY_PATH to point to something
else, that seems like a strange configuration, was that ever intended to
be supported?
That one was supposed to let ld know where the library dir is.
If anyone else actually used it for something else, well, as I said,
they can always use -L/some/path -lfoo as they always could.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Fri, 27 Jan 2023 23:46:10 +0300
DJ, Eli: I'd like to apply this patch. Any objections?
I won't fight its inclusion, but I wonder whether all of the aspects
of this patch have been considered. I'm worried by the changes in
behavior this patch brings. At least the following stand out:
the code will no longer heed DXE_LD_LIBRARY_PATH and DJDIR
I documented that in the applied patch:
https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/docs/kb/wc206.txi https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/docs/kb/wc206.txi.diff?r1=1.15&r2=1.16
makefile.dxe uses "?=", which AFAICT we never used in the DJGPP
build tree
I can revert that part: Tell me?
What if someone wants to use those
environment variables to tweak the build of a DXE?
One can simply use -L/some/path -lfoo (verified that it works)
Also, this comment no longer describes what the code does, after the change:
/* Allright, now run the assembler on the resulting file */
- sprintf(cmdbuf, "%s -o %s %s", dxe_as, TEMP_O_FILE, TEMP_S_FILE);
+ sprintf(cmdbuf, "%s -c -o %s %s", dxe_cc, TEMP_O_FILE, TEMP_S_FILE);
Change to something like this??
/* Allright, now build resulting file */
makefile.dxe uses "?=", which AFAICT we never used in the DJGPP
build tree
I can revert that part: Tell me?
If it is not necessary, I think reverting it would be best.
[...]the code will no longer heed DXE_LD_LIBRARY_PATH and DJDIR
I documented that in the applied patch:
https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/docs/kb/wc206.txi
https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/docs/kb/wc206.txi.diff?r1=1.15&r2=1.16
Instead of documenting, could we keep the previous behavior?
[...]One can simply use -L/some/path -lfoo (verified that it works)
OK, but can we actually still honor those variables in the new code,
so that if someone does use them, they could still use their scripts
and build procedures?
I don't know. DJGPP is a very old project, and it is sometimes used
in strange and tricky configurations for perhaps unorthodox purposes.
By removing these variables we could inadvertently break someone's
project in some rare cases. Why do that if we could instead keep the
old behavior intact?
Change to something like this??
/* Allright, now build resulting file */
Something like this. If it's important to state which programs are
run, I would say
/* Allright, now run the compiler to produce object and assembly files */
"?=" was[...]
introduced in GNU Make 3.77, but someone might be using an older
version.
I don't know. DJGPP is a very old project, and it is sometimes used
in strange and tricky configurations for perhaps unorthodox purposes.
One downside of the new version is that it does nıt seem to work with
gcc2.95 as tested under dosbox -- the -T dxe.ld switches doesn't seem
to work and it spits the same multiple sections error.
Don't know whether we actually expect dxe3gen to work with gcc2.95 is
another matter: Should we care?
Do we understand why it doesn't work with GCC 2.95? If so, can you
explain the reasons?
You mean, even if it won't be used, compute the libdir from either
DXE_LD_LIBRARY_PATH or DJDIR and add it as -L ?
AFAIK, DJDIR is always set in DJGPP.
The original code used
DXE_LD_LIBRARY_PATH if it was defined, else fell back to DJDIR. I
think either keeping that, or maybe adding one more fallback, for when neither DXE_LD_LIBRARY_PATH nor DJDIR is define, would be a backward-compatible change.
I don't know. DJGPP is a very old project, and it is sometimes used
in strange and tricky configurations for perhaps unorthodox purposes.
With those in mind, what do you think about compatibility with old
gcc versions? I found that at least gcc-2.95 doesn't work after this
patch possibly because it doesn't handle -T dxe.ld on the command
line.
I thought you said that if actually invoked from the shell prompt, it
did handle "-T dxe.ld"?
If that is not true, can we use -Xlinker or -Wl instead, so as to
communicate this option directly to the linker?
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Sat, 28 Jan 2023 10:55:47 +0300
makefile.dxe uses "?=", which AFAICT we never used in the DJGPP
build tree
I can revert that part: Tell me?
If it is not necessary, I think reverting it would be best.
Sure, I can do that.
the code will no longer heed DXE_LD_LIBRARY_PATH and DJDIR
I documented that in the applied patch:
https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/docs/kb/wc206.txi
https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/docs/kb/wc206.txi.diff?r1=1.15&r2=1.16
Instead of documenting, could we keep the previous behavior?[...]
One can simply use -L/some/path -lfoo (verified that it works)
OK, but can we actually still honor those variables in the new code,[...]
so that if someone does use them, they could still use their scripts
and build procedures?
I don't know. DJGPP is a very old project, and it is sometimes used
in strange and tricky configurations for perhaps unorthodox purposes.
By removing these variables we could inadvertently break someone's
project in some rare cases. Why do that if we could instead keep the
old behavior intact?
You mean, even if it won't be used, compute the libdir from either DXE_LD_LIBRARY_PATH or DJDIR and add it as -L ?
I don't know. DJGPP is a very old project, and it is sometimes used
in strange and tricky configurations for perhaps unorthodox purposes.
With those in mind, what do you think about compatibility with old
gcc versions? I found that at least gcc-2.95 doesn't work after this
patch possibly because it doesn't handle -T dxe.ld on the command
line.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
<djgpp@delorie.com>
Date: Sat, 28 Jan 2023 12:08:42 +0300
If that is not true, can we use -Xlinker or -Wl instead, so as to
communicate this option directly to the linker?
I tried doing the following, and it doesn't work even with my gcc-3.4.6
Am I doing something wrong?
I don't know. If you use this and add -v to the switches, what does
GCC show for the ld command it invokes, and how is that different from
the original code, where -T is supplied on the GCC command line?
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
<djgpp@delorie.com>
Date: Sat, 28 Jan 2023 11:07:07 +0300
This can be a show stopper, so I _can_ revert the whole patch: The
patch was made for the whole purpose of dxe3gen finding -lgcc (and
-lstdc++) automatically in the first place, and one can just do the
manual labor of copying them to $(DJDIR)/lib easily (a documentation
about it from someone would be nice.)
Having "-L$(DJDIR)/lib" and using GCC to find the standard libraries
are not contradicting goals, are they? The -L switch just says "look
in that directory as well", it doesn't replace the standard
directories.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]"
<djgpp@delorie.com>
Date: Sat, 28 Jan 2023 12:12:50 +0300
On 1/28/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: Sat, 28 Jan 2023 11:07:07 +0300
This can be a show stopper, so I _can_ revert the whole patch: The
patch was made for the whole purpose of dxe3gen finding -lgcc (and
-lstdc++) automatically in the first place, and one can just do the
manual labor of copying them to $(DJDIR)/lib easily (a documentation
about it from someone would be nice.)
Having "-L$(DJDIR)/lib" and using GCC to find the standard libraries
are not contradicting goals, are they? The -L switch just says "look
in that directory as well", it doesn't replace the standard
directories.
Well, try doing the following horrible -L :
-L/usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6
because, unlike libc.a, libgcc.a isn't under $(DJDIR)/lib
at least not in cross- environments -- really do not know
about a native installation. That was the original issue.
OK, but still: there should be no problem with having both on the
command line, right?
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Sat, 28 Jan 2023 12:48:06 +0300
/usr/local/cross-djgpp/libexec/gcc/i586-pc-msdosdjgpp/3.4.6/collect2
-o dxe_tmp.o -L/usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6 -L/usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/../../../../i586-pc-msdosdjgpp/lib
-X -S -r -T dxe.ld au.o ac97_def.o dpmi_c.o mdma.o pcibios.o sc_cmi.o sc_e1371.o sc_ich.o sc_inthd.o sc_sbl24.o sc_sbliv.o sc_sbxfi.o
sc_via82.o tim.o udivdi3.o -Tdjgpp-x.djl
/usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/../../../../i586-pc-msdosdjgpp/bin/stubify
-v dxe_tmp.o
stubify for djgpp V2.X executables, Copyright (C) 1995-2003 DJ Delorie stubify: dxe_tmp.o -> dxe_tmp.exe
dxe_tmp.o: linker output file has more than one section
Note that additional "-Tdjgpp-x.djl" at the end which screws up everything.
Note that additional "-Tdjgpp-x.djl" at the end which screws up everything.
What if you use both -T and -Xlinker -T? IOW, pass -T both to GCC and
to the linker directly?
If this still doesn't work, can you show the output of "gcc -dumpspecs"
from GCC 2.95?
OK, but still: there should be no problem with having both on the
command line, right?
No, no problems. But detecting and correctly using -lgcc was the
original goal.
But -L doesn't contradict that goal, does it?
Looks like this is becoming a hassle. Revert the patch and document
the -lgcc issue instead? (Even though I did like the result of the
patch where it does run..)
I'm sorry I'm causing the hassle,
but can we please not give up just
yet, and see if we can have the cake and eat it, too?
When I launch the game though I get an unresolved symbol _stpcpy. But the same
error happens with an unpatched dxe3gen.
Note that additional "-Tdjgpp-x.djl" at the end which screws up everything.
What if you use both -T and -Xlinker -T? IOW, pass -T both to GCC and
to the linker directly?
If this still doesn't work, can you show the output of "gcc -dumpspecs"
from GCC 2.95?
OK, but still: there should be no problem with having both on the
command line, right?
No, no problems. But detecting and correctly using -lgcc was the
original goal.
But -L doesn't contradict that goal, does it?
Looks like this is becoming a hassle. Revert the patch and document
the -lgcc issue instead? (Even though I did like the result of the
patch where it does run..)
I'm sorry I'm causing the hassle,
but can we please not give up just
yet, and see if we can have the cake and eat it, too?
Note that additional "-Tdjgpp-x.djl" at the end which screws up
everything.
What if you use both -T and -Xlinker -T? IOW, pass -T both to GCC and
to the linker directly?
That works with gcc-3.4.6, but not with gcc-2.95: adding -v to command
line shows that gcc295 invokes ld with -Tdjgpp.djl -T dxe.ld
If this still doesn't work, can you show the output of "gcc -dumpspecs"
from GCC 2.95?
Attached as 295SPECS.TXT [EDIT: really attached it this time.]
OK, I see the problem now. So this means people who use GCC 2.95 will
have to use the previous version of dxe3gen. In that case, I think
I'm okay with documenting this and ignoring the problem with GCC 2.95.
OK, but still: there should be no problem with having both on the
command line, right?
No, no problems. But detecting and correctly using -lgcc was the
original goal.
But -L doesn't contradict that goal, does it?
I'm trying to understand your question and how you see things:
What I'm saying is, needing to add an additional -L/some/path for
-lgcc is really counter-intuitive and unexpected. I guess someone
has to run gcc -print-libgcc-file-name to manually detect it and
than add it to his own command line.
Sure, but we are already talking about someone who does something very non-standard.
I just prefer that we leave those hypothetical people a
way of keeping their setups, whatever they are, and I think supporting
DJDIR and DXE_LD_LIBRARY_PATH for adding -L options to the command
line cannot do any harm to people who use the standard directories,
right?
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Sat, 28 Jan 2023 14:39:17 +0300
Note that additional "-Tdjgpp-x.djl" at the end which screws up everything.
What if you use both -T and -Xlinker -T? IOW, pass -T both to GCC and
to the linker directly?
That works with gcc-3.4.6, but not with gcc-2.95: adding -v to command line shows that gcc295 invokes ld with -Tdjgpp.djl -T dxe.ld
If this still doesn't work, can you show the output of "gcc -dumpspecs" from GCC 2.95?
Attached as 295SPECS.TXT [EDIT: really attached it this time.]
OK, but still: there should be no problem with having both on the
command line, right?
No, no problems. But detecting and correctly using -lgcc was the
original goal.
But -L doesn't contradict that goal, does it?
I'm trying to understand your question and how you see things:
What I'm saying is, needing to add an additional -L/some/path for
-lgcc is really counter-intuitive and unexpected. I guess someone
has to run gcc -print-libgcc-file-name to manually detect it and
than add it to his own command line.
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Sat, 28 Jan 2023 16:08:52 +0300
I just prefer that we leave those hypothetical people a
way of keeping their setups, whatever they are, and I think supporting DJDIR and DXE_LD_LIBRARY_PATH for adding -L options to the command
line cannot do any harm to people who use the standard directories,
right?
Was the discussion in this section only about DXE_LD_LIBRARY_PATH and/
or DJDIR support? (I knew we were speaking about different things :)
No, I am not against restoring DXE_LD_LIBRARY_PATH and/or DJDIR env
vars recognition.
BTW, if I revert the patch and go back to the previous version, -lgcc
problem can be easily worked around when using a makefile, like:
LIBGCCDIR = $(dir $(shell $(CC) -print-libgcc-file-name))
my.dxe:
dxe3gen -o my.dxe -E _sym -U $(OBJS) -L$(LIBGCCDIR) -lgcc
I even created a documentation patch to dxegen.txi for it. Should we
really keep the patch in, or revert it?
BTW, if I revert the patch and go back to the previous version, -lgcc
problem can be easily worked around when using a makefile, like:
LIBGCCDIR = $(dir $(shell $(CC) -print-libgcc-file-name))
my.dxe:
dxe3gen -o my.dxe -E _sym -U $(OBJS) -L$(LIBGCCDIR) -lgcc
I even created a documentation patch to dxegen.txi for it. Should we
really keep the patch in, or revert it?
From: "Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Date: Sat, 28 Jan 2023 16:21:48 +0300
BTW, if I revert the patch and go back to the previous version, -lgcc problem can be easily worked around when using a makefile, like:
LIBGCCDIR = $(dir $(shell $(CC) -print-libgcc-file-name))
my.dxe:
dxe3gen -o my.dxe -E _sym -U $(OBJS) -L$(LIBGCCDIR) -lgcc
I even created a documentation patch to dxegen.txi for it. Should we
really keep the patch in, or revert it?
And it is unnecessary behavior change when there is actually a solution
so I vote for reverting.
BTW, if I revert the patch and go back to the previous version, -lgcc
problem can be easily worked around when using a makefile, like:
LIBGCCDIR = $(dir $(shell $(CC) -print-libgcc-file-name))
my.dxe:
dxe3gen -o my.dxe -E _sym -U $(OBJS) -L$(LIBGCCDIR) -lgcc
I even created a documentation patch to dxegen.txi for it. Should we
really keep the patch in, or revert it?
And it is unnecessary behavior change when there is actually a solution
so I vote for reverting.
Fine by me, thanks.
As for documentation, is the following good? Better wording?
The text is fine, but the markup could be improved:
+@item
+Linking to gcc-provided libraries like libgcc may need special care,
libgcc should be in @file
+because the linker may have no idea where libgcc.a is. One solution
libgcc.a likewise
+to that when using a makefile is, retrieving the libgcc directory and
+combining it with -L before -lgcc:
"-L" and "-lgcc" are command-line options, so the suitable markup for
them is @option.
Also, with removing DXE_LD_LIBRARY_PATH, the concern was that it
could break existing makefiles. But now the accepted solution is... to
break existing makefiles?
On 2023-01-28 15:12, Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com] wrote:
OK, patch reverted,
As for documentation, is the following good? Better wording?
The text is fine, but the markup could be improved:
+@item
+Linking to gcc-provided libraries like libgcc may need special care,
libgcc should be in @file
+because the linker may have no idea where libgcc.a is. One solution
libgcc.a likewise
+to that when using a makefile is, retrieving the libgcc directory and >>>> +combining it with -L before -lgcc:
"-L" and "-lgcc" are command-line options, so the suitable markup for
them is @option.
Documentation patch is applied as
https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/dxe/dxegen.txi.diff?r1=1.9&r2=1.10
Thanks.
I don't really like this "solution", it just makes it the user's problem.
How likely is it that someone uses the latest version of dxe3gen, but is somehow stuck with such an ancient (nearly 25 years old) version of gcc? At some point you'll just have to say, for gcc < X, use dxe3gen Y.
For DXE_LD_LIBRARY_PATH, that can be added easily as -L dir, and won't break anything. But not having this set should not be an error.
For DJDIR, there is only one valid place it can point to, and gcc already knows
where to find it. I don't think a native gcc even works without DJDIR set. So
it doesn't make sense to also parse it in dxe3gen.
OK, patch reverted,
As for documentation, is the following good? Better wording?
The text is fine, but the markup could be improved:
+@item
+Linking to gcc-provided libraries like libgcc may need special care,
libgcc should be in @file
+because the linker may have no idea where libgcc.a is. One solution
libgcc.a likewise
+to that when using a makefile is, retrieving the libgcc directory and
+combining it with -L before -lgcc:
"-L" and "-lgcc" are command-line options, so the suitable markup for
them is @option.
Documentation patch is applied as https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/dxe/dxegen.txi.diff?r1=1.9&r2=1.10
Thanks.
Date: Sat, 28 Jan 2023 18:01:44 +0100
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
I don't really like this "solution", it just makes it the user's problem. >>>
How likely is it that someone uses the latest version of dxe3gen, but is >>> somehow stuck with such an ancient (nearly 25 years old) version of gcc? At
some point you'll just have to say, for gcc < X, use dxe3gen Y.
For DXE_LD_LIBRARY_PATH, that can be added easily as -L dir, and won't break
anything. But not having this set should not be an error.
For DJDIR, there is only one valid place it can point to, and gcc already knows
where to find it. I don't think a native gcc even works without DJDIR set. So
it doesn't make sense to also parse it in dxe3gen.
Also, with removing DXE_LD_LIBRARY_PATH, the concern was that it could break >> existing makefiles. But now the accepted solution is... to break existing >> makefiles? That logic is hard to follow.
If you can propose a patch that caters to your use case without
breaking the "traditional" one, please do, and let's take it from
there.
GCC 2.95 is not a blocking problem, from my POV. But I don't want to
lose support for DJDIR and DXE_LD_LIBRARY_PATH, because someone could
have set them in their build procedures for some reason, and have them
point to some strange places that neither me nor you can imagine.
Are there any fundamental problems that would preclude invoking GCC
instead of ld (so that your case is supported), but still have the -L
switch added to the GCC command line, whose argument is derived from DXE_LD_LIBRARY_PATH or from DJDIR if those are set? IOW, can we have
the code work as you wanted when these two variables aren't set, but
add the additional -L switch when they are?
Also, with removing DXE_LD_LIBRARY_PATH, the concern was that it
could break existing makefiles. But now the accepted solution is... to
break existing makefiles?
How so?? I don't see any breakage to existing makefiles at all,
care to explain?
Date: Sat, 28 Jan 2023 18:27:19 +0100
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
It implies that, if one wants to build a DXE project that was written for the native compiler (where libc, libgcc, libstc++ are all in one directory)
Date: Sat, 28 Jan 2023 18:01:44 +0100
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
I don't really like this "solution", it just makes it the user's problem.
How likely is it that someone uses the latest version of dxe3gen, but is somehow stuck with such an ancient (nearly 25 years old) version of gcc? At
some point you'll just have to say, for gcc < X, use dxe3gen Y.
For DXE_LD_LIBRARY_PATH, that can be added easily as -L dir, and won't break
anything. But not having this set should not be an error.
For DJDIR, there is only one valid place it can point to, and gcc already knows
where to find it. I don't think a native gcc even works without DJDIR set. So
it doesn't make sense to also parse it in dxe3gen.
Also, with removing DXE_LD_LIBRARY_PATH, the concern was that it could break existing makefiles. But now the accepted solution is... to break existing makefiles? That logic is hard to follow.
Date: Sat, 28 Jan 2023 18:27:19 +0100
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
It implies that, if one wants to build a DXE project that was written for the
native compiler (where libc, libgcc, libstc++ are all in one directory)
No, in a native installation libgcc and libstdc++ are in a directory different from libc. We just didn't support linking against those two libraries because AFAIU it was never needed by anyone, definitely in
the case of libstdc++.
We just didn't support linking against those two
libraries because AFAIU it was never needed by anyone,
Date: Sat, 28 Jan 2023 19:12:06 +0100
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
No, in a native installation libgcc and libstdc++ are in a directory different from libc. We just didn't support linking against those two libraries because AFAIU it was never needed by anyone, definitely in
the case of libstdc++.
On my end, libc and libstdc++ are in %DJDIR%\lib\. But I see libgcc is in %DJDIR%\lib\gcc\djgpp\12\.
It is probably possible to configure gcc/libstdc++ to place these in any arbitrary location. I think it's best if dxe3gen and makefile writers have no
knowledge of a user's particular configuration, and simply leave it to gcc to figure it out.
Date: Sat, 28 Jan 2023 19:09:56 +0100
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
Are there any fundamental problems that would preclude invoking GCC
instead of ld (so that your case is supported), but still have the -L switch added to the GCC command line, whose argument is derived from DXE_LD_LIBRARY_PATH or from DJDIR if those are set? IOW, can we have
the code work as you wanted when these two variables aren't set, but
add the additional -L switch when they are?
Sure, that should be possible. Starting from the patch I submitted earlier, simply adding DXE_LD_LIBRARY_PATH via -L will achieve that.
For DJDIR, again, having it set to anything other than the djgpp install location is *always* user error. Many things rely on this, and to me it doesn't seem very useful to support invalid configurations in dxe3gen.
On 1/28/23, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
We just didn't support linking against those two
libraries because AFAIU it was never needed by anyone,
Exactly.
And anyone who needed it copied it (them) to a directory
accessible by cross-ld and used it that way. So, nothing has
changed, hence no incompatibility introduced.
Date: Sat, 28 Jan 2023 19:12:06 +0100
From: "J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com>
No, in a native installation libgcc and libstdc++ are in a directory
different from libc. We just didn't support linking against those two
libraries because AFAIU it was never needed by anyone, definitely in
the case of libstdc++.
On my end, libc and libstdc++ are in %DJDIR%\lib\. But I see libgcc is in >> %DJDIR%\lib\gcc\djgpp\12\.
libgcc should be in a version-specific directory under either lib/gcc
or lib/gcc-lib. libstdc++ is normally also in that subdirectory, I
don't know why you have it in lib. It is version-specific, so cannot
be in the general lib directory.
It is probably possible to configure gcc/libstdc++ to place these in any
arbitrary location. I think it's best if dxe3gen and makefile writers have no
knowledge of a user's particular configuration, and simply leave it to gcc to
figure it out.
Yes, that's true. No argument there. I'm just saying that if someone
has some unusual (read: crazy) non-standard configuration, where
libraries can be found via these two environment variables, we
shouldn't break those unusual configurations.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 344 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 83:04:20 |
| Calls: | 7,538 |
| Calls today: | 1 |
| Files: | 12,720 |
| Messages: | 5,645,345 |