Mail Archives: djgpp/1999/09/23/20:09:02
On Wed, 22 Sep 1999, Johan Venter wrote:
> > At least this is how things work with the stock djgpp.djl linker
> > script that is supplied with djdevNNN.zip. If you edited or replaced
> > that script, your setup might be different. LD *does* know how to
> > create .exe files directly, we just don't use that feature by default
> > (for some subtle but important reasons).
>
> Not to bother, Eli, but would you perhaps be willing to elaborate those
> reasons?
Two reasons come to mind:
- Using `stubify' makes sure you always get the latest stub, from
whatever version of djdev you have installed. In contrast, the
stub built into ld.exe is usually old (it is part of the Binutils
distribution, and so always lags behind). There is a way to force
ld.exe to use the stub of your choice, but the default DJGPP setup
currently doesn't use this feature (v2.03 will), and I don't trust
users to do that on their own (they'd need to read the fine print
of the docs to know how ;-). Trying to debug users' problems
which stem from using an outdated stub can be very tedious...
- If ld.exe is configured to produce a stubbed executable, then a
command like "gcc -o foo" generates `foo' that is a stubbed
program (as opposed to a raw COFF image). Some ported utilities,
like GNU `install', do special things for raw COFF images, but not
for stubbed executables. E.g., "install foo c:/djgpp/bin/foo"
will silently create `foo.exe' in the target directory, but only
if `foo' is a COFF image. (To be changed in the next port of
Fileutils, but when that will happen is anybody's guess ;-). This
breaks "make install" targets in some packages, because DOS
refuses to run a program that lacks the .exe extension.
- Raw text -