Date: Sun, 14 Jan 2001 13:49:22 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc: djgpp-workers AT delorie DOT com
Subject: RE: Where does gcc -o foo make foo.exe
In-Reply-To: <NEBBIOJNGMKPNOBKHCGHEEJBCAAA.tim.van.holder@pandora.be>
Message-ID: <Pine.SUN.3.91.1010114134743.26583D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sun, 14 Jan 2001, Tim Van Holder wrote:

> > Yes (I assume you meant /dev/env/DJDIR/bin/stubify.exe).  But I wonder 
> > whether we should add to this list SELFDIR/stubify.exe, where SELFDIR is 
> > the directory part of ld.exe's argv[0]?  That would allow ld.exe to DTRT 
> > even if DJGPP.ENV is not there (since DJDIR is computed by the code which 
> > reads DJGPP.ENV).
> I believe the stub loading is done by BFD, not ld; so getting (portably) at
> the path to the current executable may not be obvious.

??? BFD may be _reading_ the stub, but I'm guessing that it's the 
application (ld, in this case) which tells it from what file to read it.  
Otherwise, that would mean that GO32STUB etc. are also pushed to the BFD 
level, which I don't think is true.