possible BinUtils 2.17+ bug (a.out is stubbed, didn't use to be)

[Rugxulo]

Hey guys,
Recently it was discovered by CWS and myself that "gcc myfile.c -o
myfile" produces myfile, myfile.exe as usual. And yet, BinUtils 2.16.1
doesn't seem to stub the "myfile" object (with the .EXE header) but
later BinUtils do. Isn't this a bug? I tried swapping out DJGPP 2.04
with 2.03p2 to see if it was STUBIFY, but nope, seems to (most likely)
be a bug in latest BinUtils 2.17 or newer (2.16.1 didn't have this
problem although DJGPP ELF's 2.16 does, oddly).

Just FYI in case anyone stumbles upon this or knows a quick fix.

[Andris Pavenis]

Rugxulo kirjoitti:

I suspect the reason is linker scripts. Sometimes ago GCC provided
it's own linker script which caused binutils not to add stub (search
file djgpp-x.djl in GCC package, such file djgpp.djl is also provided
in djdev20X packages for really old GCC versions.

Some time in the past linker script did not any more provided in
GCC packages (it does not logically belong to GCC, but to binutils).
As result the output format coff-go32-exe from binutils default
linker script were used instead of coff-go32.

I guess the reason was trying to add stub automatically from linker.
In that case there would be no need to invoke stubify from GCC. However
in that case without invoking stubify from 'gcc myfile.c -o myfile'
one woul get only file myfile but not myfile.exe. It would break things
in cases when also myfile.exe is expected to be generated.

I cannot immediately say whether changing binutils default output
format to coff-go32 would not break anything.

You can try to:
1) take the default linker script from binutils
($DJDIR/lib/ldscripts/i386go32.x)
2) copy it to the directory where myfile.c (or which file You are compiling)
is located with different name (eg. i386go32.djl)
3) change output format in i386go32.djl to coff-go32
4) specify linker script with GCC option -T:
gcc myfile.c -Ti386go32.djl -o myfile

Andris

PS. As far as I remember files in $DJDIR/lib/ldscripts are there for
reference only and not used by ld.exe, so there is no use from
modifying them in place.
PS2. I did try any of this practically now as I'm writing this message
under Linux.