<cmath> patch anyone?

[janezz55]

It should be easy to make std::trunc() work. First we need to cajole gcc into using C99 math.h (-D_GLIBCXX_USE_C99_MATH_TR1), then several ::using lines need to be removed and a trunc() implementation for double needs to be inserted. Will someone write the patch or do I need to?

[Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

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

Thanks,
Frank

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 1/22/23, Frank Sapone (emoad...@gmail.com) [via

Do you not link to libstdc++ (and libgcc) ?
If you really do and it still happens, then I don't know.

Is the project open?

[Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

On 1/22/2023 2:15 AM, Ozkan Sezer (sez...@gmail.com) [via

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

The interesting thing about the -lstdc++ -lc is that I'm using the
Andrewwu cross-compiler which has mingw32 packaged and ready to go on
Windows.  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 and could
be part of my issue here?

Frank

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

> By link, you mean for dxe3gen?

Yes

> If yes, then I tried that.

Huh..

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

> which I suspect is incorrect

I don't see how..

[Frank H. Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

On Sunday, January 22, 2023, Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com] <djgpp@deloriecom> wrote:

>  And no, the project is not open unfortunately.

Is this dk ?

 

Yes

 

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

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, but its been a couple of years.  Just seems wrong to have to copy important libs like that?

Frank

PS Apologies in advance for bad formatting, on a phone today.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

I'd like to hear the result. Remember that
dxe3gen --show-unres xxx.dxe
will output the missing symbols in the 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
>>
>> Sounds correct from what you write,
>
> Having to copy the lib? I dont remember doing that,

I (we) had to do that when building game dxes of sin
which link to libstdc++ and libgcc

> Just seems wrong to have to copy
> important libs like that?

That's a shortcoming of dxe3gen with gcc-provided libraries,
needs to be addressed but no one cared (or no one reported
the issue probably.)

[Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

>> 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.
> I'd like to hear the result. Remember that
> 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 copy
>> important libs like that?
> That's a shortcoming of dxe3gen with gcc-provided libraries,
> 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?  I'd do it, but I really do not know as much about
GCC and DJGPP inner-workings like you do. :)

Thanks,
Frank

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

>>> 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.
>> I'd like to hear the result. Remember that
>> 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.

Good to see that it now works.

Just looked at dxe3gen documentation, and it says:

Usage: dxe3gen [-o output.dxe] [options] [object-files] [ld-options]
or: dxe3gen -1 output.dxe symbol input.o [input2.o ... -lgcc -lc]

that 'ld-options' is always at the end which includes any link libs.
So, the order of arguments _is_ important.

>>> Just seems wrong to have to copy
>>> important libs like that?
>> That's a shortcoming of dxe3gen with gcc-provided libraries,
>> 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.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

On 2023-01-23 05:00, Ozkan Sezer (sez...@gmail.com) [via dj...@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.

[Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com]]

It is should be easy:

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

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 1/25/23, Andris Pavenis (andris....@iki.fi) [via

No '*post_link:' in my gcc's dumpspecs (gcc-3.4.6, cross- from linux.)

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

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.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

Sorry, that's incorrect, earlier versions *do* call stubify, but via
link_command. I thought they used the stub that ld attaches.

So, if gcc < 4.x must be supported, that does make things more complicated.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

On 2023-01-23 05:00, Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com] wrote:
>>>> Just seems wrong to have to copy
>>>> important libs like that?
>>> That's a shortcoming of dxe3gen with gcc-provided libraries,
>>> 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.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 1/26/23, J.W. Jagersma (jwjag...@gmail.com) [via

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

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

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.

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

I tried it with a basic hello-world that uses std::vector, and got a long list
of unresolved references. But I get the same list with an unpatched dxe3gen.
It does make a .dxe file with -U.

[Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

> 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

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

Thanks. It builds fine for me with the patched dxe3gen, no warnings, both with
and without -lgcc.

$ ~/djgpp-cvs/src/dxe/dxe3gen --show-exp sndpci.dxe
_AU_close
_AU_writedata
_AU_start
_AU_stop
_AU_setrate
_AU_getinfo
_AU_setmixer_all
_AU_cardbuf_space
_AU_search

$ ~/djgpp-cvs/src/dxe/dxe3gen --show-unres sndpci.dxe
_sprintf
_free
___djgpp_nearptr_enable
_clock
_int86
___djgpp_base_address
_calloc
_disable
_enable

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

Thanks, tried this too. I had to add -fcommon -Wno-error in all makefiles for
gcc 12.2. Then everything builds okay with the patched dxe3gen.

When I launch the game though I get an unresolved symbol _stpcpy. But the same
error happens with an unpatched dxe3gen.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

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?

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 1/27/23, Ozkan Sezer <sez...@gmail.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.

And, `file` command reports differently for the two versions:

dxe_tmp-0.o: Intel 80386 COFF object file, no line number info, not
stripped, 1 section, symbol offset=0xc104, 433 symbols, 1st section
name ".text"

dxe_tmp-1.o: Intel 80386 COFF executable, no line number info, not
stripped, 3 sections, symbol offset=0xc548, 437 symbols, optional
header size 28

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

On 2023-01-27 19:10, Ozkan Sezer (sez...@gmail.com) [via dj...@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.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 1/27/23, J.W. Jagersma (jwjag...@gmail.com) [via

Yes, this one does work, and yields an identical dxe.

DJ, Eli: I'd like to apply this patch. Any objections?

[DJ Delorie]

"Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]"

<dj...@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.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

Patch now applied to cvs. Thanks.

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@delorie.com>
> Date: Fri, 27 Jan 2023 22:23:40 +0300

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

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

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

> Date: Fri, 27 Jan 2023 23:00:28 +0300
> Cc: dj...@delorie.com

If you aren't going to wait for me to answer your questions, why ask
me?

As it happens, when I saw the question, I actually read the patch,
thought about it, and posted a non-trivial response. I'd hope that
the effort I made will not be wasted.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

>> 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 */

> If you aren't going to wait for me to answer your questions, why ask
> me?

I got one response, thought it was enough. Sorry -- will wait
all next time.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

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.

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

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.

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

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

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

On 2023-01-27 22:03, Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com] wrote:
>>> . 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.

Agree, -L should be used for non-standard dirs.

>> I also had yet to update the manual for the v2 patch:
>
> I already updated the changelog, if that's what you mean.

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.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

> 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

I can do that.

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

I wouldn't know about that,

> so they will
> already have a v1.0.4. I think it's a good idea to signal that this
> version is different.

No objections from me.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 1/28/23, Ozkan Sezer <sez...@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?

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

I am also curious about since which version -T script is honored on
the gcc command line.

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@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

Instead of documenting, could we keep the previous behavior?

> > 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. "?=" was
introduced in GNU Make 3.77, but someone might be using an older
version. If the functionality of "?=" is really needed here, we could
instead use its equivalent

ifeq ($(origin FOO), undefined)
FOO = bar
endif

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

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?

> > 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 */

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 */

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> Date: Fri, 27 Jan 2023 21:53:48 +0100
> From: "J.W. Jagersma (jwjag...@gmail.com) [via dj...@delorie.com]" <dj...@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?

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?

IOW, given the age of DJGPP, we should strive not to make breaking
changes unless we have a very good reason to do so.

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

Why is ?= needed here, and a simple = is not enough?

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

Running "gcc -c -o" is hardly described accurately as "running the
assembler". If we want to go to that level, then the comment should
say something like "run the driver, the compiler, and the assembler"
(not that I think we should say that).

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

Agreed.

Thanks.

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@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.

Why cannot we tweak the way we compute the command arguments to still
honor these two variables? It's a simple matter of reusing code that
was already there, and was used for ages, no?

IOW, is there a real reason for removing the code which used the
values of those two environment variables?

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@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?

Do we understand why it doesn't work with GCC 2.95? If so, can you
explain the reasons?

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

>> 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 */

OK, can do.

> "?=" 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.

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 only tested gcc-3.4.6, maybe older ones don't work either.)

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

As I understand it (someone correct me if I'm wrong), it ignores the
-T dxe.ld switches on its command line.

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

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@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.

Thanks.

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

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?

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@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.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

Not in cross- environments, but I hear you,

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

OK, can compute a libdir from those env vars and add as -Lxxx

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

I tried doing the following, and it doesn't work even with my gcc-3.4.6
Am I doing something wrong?

Index: dxe3gen.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/dxe/dxe3gen.c,v
retrieving revision 1.26
diff -u -p -r1.26 dxe3gen.c
--- dxe3gen.c 27 Jan 2023 20:00:04 -0000 1.26
+++ dxe3gen.c 28 Jan 2023 09:04:57 -0000
@@ -198,7 +198,7 @@
#define IS_SLASH(path) (((path) == '/') || ((path) == '\\'))
#define IS_DIR_SEPARATOR(path) (IS_SLASH(path) || ((path) == ':'))

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

#define IS_VALID_CIE(id) ((id) == 0)
@@ -438,8 +438,10 @@ static void process_args(int argc, char
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;
+ new_argv[5] = "-Xlinker";
+ new_argv[6] = "-T";
+ new_argv[7] = "-Xlinker";
+ new_argv[8] = dxe_sc;

if (!strcmp(base_name(argv[0]), "dxegen"))

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 1/28/23, Eli Zaretskii (el...@gnu.org) [via dj...@delorie.com]

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.

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@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?

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

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

> Date: Sat, 28 Jan 2023 12:12:50 +0300

OK, but still: there should be no problem with having both on the
command line, right?

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 1/28/23, Eli Zaretskii (el...@gnu.org) [via dj...@delorie.com]
<dj...@delorie.com> wrote:

Before:

Reading specs from /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/specs
Configured with: ../gcc-3.46/configure --prefix=/usr/local/cross-djgpp
--target=i586-pc-msdosdjgpp
--with-headers=/usr/local/cross-djgpp/i586-pc-msdosdjgpp/include
--enable-languages=c,c++ --disable-libgcj --disable-libada
--disable-nls
Thread model: single
gcc version 3.4.6
/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 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 -T dxe.ld
/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


After:

Reading specs from /usr/local/cross-djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.6/specs
Configured with: ../gcc-3.46/configure --prefix=/usr/local/cross-djgpp
--target=i586-pc-msdosdjgpp
--with-headers=/usr/local/cross-djgpp/i586-pc-msdosdjgpp/include
--enable-languages=c,c++ --disable-libgcj --disable-libada
--disable-nls
Thread model: single
gcc version 3.4.6
/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.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

No, no problems. But detecting and correctly using -lgcc was the
original goal.

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

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@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.

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?

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

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

> Date: Sat, 28 Jan 2023 12:51:21 +0300

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? I'd like to see
if there is a solution that both fixes the problem and is
backward-compatible. See my other mail with further suggestions.

Thanks.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

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

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

No, you really are not.

> but can we please not give up just
> yet, and see if we can have the cake and eat it, too?

OK :)

[Frank Sapone (emoaddict15@gmail.com) [via djgpp@delorie.com]]

> When I launch the game though I get an unresolved symbol _stpcpy. But the same
> error happens with an unpatched dxe3gen.

Yes, later versions of GCC with DJGPP resolve strcpy to stpcpy
internally.  I have not looked at the code, but I assume it's some kind
of optimization strategy based on strings with known sizes. I believe
this started in GCC4.

Simply add DXE_EXPORT(stpcpy) to the dos/dxe.c file with the rest of the
DXE_EXPORT table and recompile.  It's possible there may be some other
functions like this in string.h that you will have to do.

Frank

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@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, 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?

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

I still don't know what other gcc versions would have an issue
with the new version, e.g. gcc 3.0, 3.1, 3.2 or 3.3: I only tested
with 3.4, so I am not 100% comfortable with the patch being in.
(Also see down below.)

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

For the record, -lgcc is not non-standart,

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

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> From: "Ozkan Sezer (sez...@gmail.com) [via dj...@delorie.com]" <dj...@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 :)

Yes, only about that.

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

I'm okay either way.

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

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

> Date: Sat, 28 Jan 2023 16:21:48 +0300

Fine by me, thanks.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

OK then, will revert shortly.

As for documentation, is the following good? Better wording?

Index: dxegen.txi
===================================================================
RCS file: /cvs/djgpp/djgpp/src/dxe/dxegen.txi,v
retrieving revision 1.7
diff -u -r1.7 dxegen.txi
--- dxegen.txi 26 Jun 2015 16:39:06 -0000 1.7
+++ dxegen.txi 28 Jan 2023 12:52:28 -0000
@@ -214,7 +214,17 @@
the module and so on. As a workaround, keep such names unexported by
filtering exported names through @kbd{-E} option.

+@item
+Linking to gcc-provided libraries like libgcc may need special care,
+because the linker may have no idea where libgcc.a is. One solution
+to that when using a makefile is, retrieving the libgcc directory and
+combining it with -L before -lgcc:
@end itemize
+@example
+LIBGCCDIR = $(dir $(shell $(CC) -print-libgcc-file-name))
+my.dxe:
+ dxe3gen -o my.dxe -E _sym -U $(OBJS) -L$(LIBGCCDIR) -lgcc
+@end example

-*- The best way is to leave the symbols unresolved and resolve them at
runtime. To tell @command{dxe3gen} to not fail on unresolved symbols, add the

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

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

> Date: Sat, 28 Jan 2023 16:40:27 +0300

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

Thanks.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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.

[J.W. Jagersma (jwjagersma@gmail.com) [via 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.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

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.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

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

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> Date: Sat, 28 Jan 2023 18:01:44 +0100
> From: "J.W. Jagersma (jwjag...@gmail.com) [via dj...@delorie.com]" <dj...@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?

[J.W. Jagersma (jwjagersma@gmail.com) [via 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), it is
now up to the user to edit the makefiles in case his/her configuration uses
multiple lib directories (as is typically the case in a cross compiler).

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> Date: Sat, 28 Jan 2023 18:27:19 +0100

> From: "J.W. Jagersma (jwjag...@gmail.com) [via dj...@delorie.com]" <dj...@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++.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

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.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

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.

[Ozkan Sezer (sezeroz@gmail.com) [via djgpp@delorie.com]]

On 1/28/23, Eli Zaretskii (el...@gnu.org) [via dj...@delorie.com]
<dj...@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.

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> Date: Sat, 28 Jan 2023 19:09:56 +0100

> From: "J.W. Jagersma (jwjag...@gmail.com) [via dj...@delorie.com]" <dj...@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.

Good.

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

Once again: adding one more -L switch to a compiler command line
cannot possibly do any harm.

[Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com]]

> Date: Sat, 28 Jan 2023 19:12:06 +0100

> From: "J.W. Jagersma (jwjag...@gmail.com) [via dj...@delorie.com]" <dj...@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.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

On 2023-01-28 21:04, Eli Zaretskii (el...@gnu.org) [via dj...@delorie.com] wrote:
>> Date: Sat, 28 Jan 2023 19:12:06 +0100
>> From: "J.W. Jagersma (jwjag...@gmail.com) [via dj...@delorie.com]" <dj...@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.

That would indicate a problem (?) with the recent gpp*b.zip packages then.
From 4.7.4 on, they all come with libstdcxx.a in lib/.

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

If you think it should be kept, then I won't object too much. A duplicate -L
entry indeed does no harm. I'm just saying it's completely redundant - native
gcc will not work with an invalid DJDIR, and it will always put %DJDIR%/lib in
the default library path.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

But then anyone else who wants to build that code, will also have modify their
installation and copy those files. So that spreads the problem out, while it
could be solved in a single location instead.