Date: Thu, 1 Jan 1998 10:24:05 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "Tony O'Bryan" <aho450s AT nic DOT smsu DOT edu>
cc: djgpp AT delorie DOT com
Subject: Re: LD looks at zip drive
In-Reply-To: <34AA59B0.5481@nic.smsu.edu>
Message-ID: <Pine.SUN.3.91.980101101741.6053A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 31 Dec 1997, Tony O'Bryan wrote:

> Yep.  I was, of course, aghast to hear that a DJGPP base utility had a
> hard-coded path in it (read that last line with a health dose of
> tongue-in-cheek).  I had automatically eliminated that as a possibility
> without a second thought.

DJGPP ports of GNU software *always* have certain path names hard-wired
into them.  That is how GNU programs are written (they all assume that
they were compiled on the same machine on which they are run), and
changing this in fundamental ways would be a *lot* of work.  Try saying
"gcc -v -c foo.c" and you will see that gcc itself has certain directories
that it looks into by default. 

What is wrong in this case is *not* that a certain path name is 
hard-coded into the binary, but that it is *always* searched.  Other 
DJGPP ports are set up in a way that they never get to those default 
directories, because they find what they are after before that.  
DJGPP.ENV usually sets things up so that this is what happens.

But in the case of LD, it searches that directory right on startup, and 
*that* is IMHO wrong.  The ported version should have been set up to 
either disable that code, or substitute a %DJDIR%-relative directory for 
it.