Mail Archives: djgpp-workers/1998/06/30/09:44:53
Date sent: Tue, 30 Jun 1998 15:16:10 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
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.)
- Raw text -