Date:	Tue, 30 Jun 1998 15:16:10 +0200 (MET DST)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
To:	Andris Pavenis <pavenis AT lanet DOT lv>
cc:	djgpp workers list <djgpp-workers AT delorie DOT com>
Subject:	Re: Some notes about DJDEV202.ZIP
In-Reply-To:	<B0000033568@stargate.astr.lu.lv>
Message-ID:	<Pine.LNX.3.93.980630151231.11669A-100000@acp3bf>
MIME-Version:	1.0

On Mon, 29 Jun 1998, Andris Pavenis wrote:

[...]
> > library dir, and the (primary) include path. But gcc already has machinery
> > for searching these files in its own private directory tree
> > (/usr/local/lib/gcc-lib/${PLATFORM}/${VERSION}/specs and friends). 
> > 
> > So why not just use that machinery, after some fiddling, if necessary and
> > be done with it?
> 
> The problem is that if $DJDIR/lib is in library search path then gcc-
> 2.8.1 searches this directory before it's own one, so files from 
> djdev201 will erroroulsy be used.

I still don't really understand why we can't convince gcc to work as it
would on Unix-systems: $DJDIR/{include,lib} would be used in place of
/usr/{include,linux}, and the compiler-specific path
$DJDIR/lib/gcc-lib/2.81/ replacing
/usr/local/lib/gcc-lib/${platform}/${version}? 

That scheme is normally sufficient to ensure that the gcc version-specific
files in its private directory (.../gcc-lib/...) are always found before
their equivalents in the system-wide path /usr/....

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -