https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68181
Bug ID: 68181
Summary: djgpp: minor linker invocation issues
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.von.s at posteo dot de
Target Milestone: ---
Created attachment 36635
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36635&action=edit
gcc/config/i386/djgpp.h patch (5.2.0)
0. The gcc frontend unconditionally instructs the linker to use a script
provided by the djgpp libraries package. It contains a few LONG(0) directives
which seem to be needed by the CRT to have some variables/memory regions
properly initialised. I'd like that it be possible to disable that linker
script. (Why? To make GRUB modules buildable with the djgpp compiler the same
way they're buildable on mingw: by building them as COFF files and then
converting them to ELF.)
1. GNU ld has been able to directly output go32 .exe files for quite some time
(before even the repository was converted to git, it seems). Therefore calling
the stubify utility is unnecessary. (However, ld names the output file a.out by
default, which confuses autoconf, so it should be passed -o a.exe unless -o was
given to gcc). Removing this dependency will simplify things a bit. (On the
other hand, the loader stub used by binutils is a bit outdated; it comes from
the 2.02 release of djgpp.)
Both issues can be resolved with the attached trivial patch. The -T option is
not passed to the linker when -nostdlib is passed to gcc (maybe -nodefaultlibs
should also do it; or maybe -dT should be passed to the linker instead). I
think that ultimately it's the djgpp CRT that ought to be fixed, but I'm not
sure how. In the meantime, this should do.
