Date: Sun, 14 Jan 2001 14:09:06 +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: <NEBBIOJNGMKPNOBKHCGHMEJCCAAA.tim.van.holder@pandora.be>
Message-ID: <Pine.SUN.3.91.1010114140416.26583G-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:

> > ??? 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.
> I just checked the current weekly snapshot; only coff-stgo32.c references
> $GO32STUB.

Thanks for looking it up.

Is there a way to move this code to the application level?  It doesn't 
seem right to me to have an obscure BFD function look at environment 
variables.

If this cannot be done, we can still make it work, either by introducing 
some global variable specific to the DJGPP port, or by having the 
application push a special variable into the environment whose value is 
the leading directory from argv[0].