Message-ID: From: "Andris Pavenis" To: Andris Pavenis , Hans-Bernhard Broeker Date: Tue, 30 Jun 1998 16:44:30 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Some notes about DJDEV202.ZIP CC: djgpp workers list References: In-reply-to: Precedence: bulk Date sent: Tue, 30 Jun 1998 15:16:10 +0200 (MET DST) From: Hans-Bernhard Broeker Subject: Re: Some notes about DJDEV202.ZIP > 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/.... > Specifying $DJDIR/lib in library search path for DJGPP is the same as doing adding this under Linux. As the result such directory is searched BEFORE any version-specific directory. For example in Linux I'm not defining library and include file directories at all unless I want add my own (then I'm doing this by options -I and -L for gcc instead of use of environement variables) If we include version specific directory there then what to do when gcc version will change as I think it is not a good idea to add all possible future version names (2.8.2, 2.9.0, pgcc-1.0.3, etc.)