Date: Thu, 23 Sep 1999 10:41:30 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Johan Venter <jventer AT writeme DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: DJGPP viruses (Re: HELP! "invalid page exception"??)
In-Reply-To: <1q1G3.22798$ei1.43431@newsfeeds.bigpond.com>
Message-ID: <Pine.SUN.3.91.990923104110.10652D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


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.