$tooldir

$tooldir

[Jeffrey A Law]

I'm sure y'all both remember the tooldir problems I introduced back in
Sept/Oct.  Thanks to you we managed to get them _mostly_ sorted out.

However, in the process, we killed the entire point behind the changes I made.
So, time to re open this can-o-worms.

The core issue is we want to be able to use a directory relative to $libsubdir
which gets us to $tooldir.  This is one of the important changes needed to
allow the gcc hierarchy to move around without needing to fiddle with -B args
or setting GCC_EXEC_PREFIX.


First requirement is we do not want to hose $tooldir uses in other Makefiles
outside of gcc -- consider a naked gdb installation we can't reference
$libsubdir because it is specific to gcc installations.

  * Thus, We do not want to change the toplevel tooldir specification, nor do
    we want to remove it from flags to pass.

  * Therefore, gcc must not use tooldir, it'll have to use a different name.
    $(gcc_relative_tooldir) or something like that.


We also do not want to hose configurations which explicitly specify locations
for tooldir or libsubdir.  For simplicity, we can avoid this if $tooldir
looks like anything other than $prefix/$target_alias or libsubdir looks like
anything other than $prefix/$libdir/gcc-lib/$target_alias/$target_version.
For that case we'll just use the $tooldir value provided by the toplevel
configury/Makefile machinery.

Am I missing any other issues?

jeff

Re: $tooldir

[Alexandre Oliva]

On Jan 19, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:

> First requirement is we do not want to hose $tooldir uses in other Makefiles
> outside of gcc

> We also do not want to hose configurations which explicitly specify locations
> for tooldir or libsubdir.

> Am I missing any other issues?

Not that I can think of.  But you reminded me of a problem I've been
thinking of fixing for quite a long time, but that I haven't been able 
to pay attention to for quite a long time: --with-as and --with-ld
can be used to hard-code the pathnames of the assembler and the linker
into gcc and collect2.

The problem is that sometimes I'd like to try a new assembler or a new
linker, and I wouldn't like to have to rebuild gcc in order to try
them, and I don't want to install versions of as and ld that might
break egcs while other users are using it.

So I came up with the following idea: if any -Bdir argument is given,
gcc would search for as and ld in those directories before trying to
use the hard-coded pathnames.

Does this sound reasonable?

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: $tooldir

[Jeffrey A Law]

  In message <orww2izgoa.fsf@araguaia.dcc.unicamp.br>you write:
  > The problem is that sometimes I'd like to try a new assembler or a new
  > linker, and I wouldn't like to have to rebuild gcc in order to try
  > them, and I don't want to install versions of as and ld that might
  > break egcs while other users are using it.
  > 
  > So I came up with the following idea: if any -Bdir argument is given,
  > gcc would search for as and ld in those directories before trying to
  > use the hard-coded pathnames.
  > 
  > Does this sound reasonable?
Yes/no.  Part of me sez, if a path was spec'd at configure time, then it
should override everything, even -B args.

Your suggested change would have the effect of overriding the configured
assembler during bootstraps.

jeff

Re: $tooldir

[Alexandre Oliva]

On Jan 26, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:

>   In message <orww2izgoa.fsf@araguaia.dcc.unicamp.br>you write:
>> The problem is that sometimes I'd like to try a new assembler or a new
>> linker, and I wouldn't like to have to rebuild gcc in order to try
>> them, and I don't want to install versions of as and ld that might
>> break egcs while other users are using it.
>> 
>> So I came up with the following idea: if any -Bdir argument is given,
>> gcc would search for as and ld in those directories before trying to
>> use the hard-coded pathnames.
>> 
>> Does this sound reasonable?
> Yes/no.  Part of me sez, if a path was spec'd at configure time, then it
> should override everything, even -B args.

> Your suggested change would have the effect of overriding the configured
> assembler during bootstraps.

Wouldn't that be good?  Then, it would use the build-tooldir as even
though it was not installed it.  I agree that this might have other
unwanted side-effects, though.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: $tooldir

[Donn Terry]

Alexandre Oliva wrote:
> 
> On Jan 26, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:
> 
> >   In message <orww2izgoa.fsf@araguaia.dcc.unicamp.br>you write:
> >> The problem is that sometimes I'd like to try a new assembler or a new
> >> linker, and I wouldn't like to have to rebuild gcc in order to try
> >> them, and I don't want to install versions of as and ld that might
> >> break egcs while other users are using it.
> >>
> >> So I came up with the following idea: if any -Bdir argument is given,
> >> gcc would search for as and ld in those directories before trying to
> >> use the hard-coded pathnames.
> >>
> >> Does this sound reasonable?
> > Yes/no.  Part of me sez, if a path was spec'd at configure time, then it
> > should override everything, even -B args.
> 
> > Your suggested change would have the effect of overriding the configured
> > assembler during bootstraps.
> 
> Wouldn't that be good?  Then, it would use the build-tooldir as even
> though it was not installed it.  I agree that this might have other
> unwanted side-effects, though.

-B should take precedence; it's something the user (OK, "I") specified,
so it should be presumed to be more recent (and thus, "more right").

In my case, I do a full compiler path bootstrap (compiler, gas,
ld), and I want to be able to build subseqent pieces with the
pieces I just built (without installing them).  I use -B to
achieve that now (non-egcs gcc).

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: $tooldir

[Donn Terry]

Alexandre Oliva wrote:
> 
> On Jan 26, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:
> 
> >   In message < orww2izgoa.fsf@araguaia.dcc.unicamp.br >you write:
> >> The problem is that sometimes I'd like to try a new assembler or a new
> >> linker, and I wouldn't like to have to rebuild gcc in order to try
> >> them, and I don't want to install versions of as and ld that might
> >> break egcs while other users are using it.
> >>
> >> So I came up with the following idea: if any -Bdir argument is given,
> >> gcc would search for as and ld in those directories before trying to
> >> use the hard-coded pathnames.
> >>
> >> Does this sound reasonable?
> > Yes/no.  Part of me sez, if a path was spec'd at configure time, then it
> > should override everything, even -B args.
> 
> > Your suggested change would have the effect of overriding the configured
> > assembler during bootstraps.
> 
> Wouldn't that be good?  Then, it would use the build-tooldir as even
> though it was not installed it.  I agree that this might have other
> unwanted side-effects, though.

-B should take precedence; it's something the user (OK, "I") specified,
so it should be presumed to be more recent (and thus, "more right").

In my case, I do a full compiler path bootstrap (compiler, gas,
ld), and I want to be able to build subseqent pieces with the
pieces I just built (without installing them).  I use -B to
achieve that now (non-egcs gcc).

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: $tooldir

[Jeffrey A Law]

  In message < orhftducc1.fsf@araguaia.dcc.unicamp.br >you write:
  > > Your suggested change would have the effect of overriding the configured
  > > assembler during bootstraps.
  > 
  > Wouldn't that be good?  Then, it would use the build-tooldir as even
  > though it was not installed it.  I agree that this might have other
  > unwanted side-effects, though.
Well, I thought the whole idea of that built-in name was to override
everything.  Maybe I misunderstood the original intentions of including
a pathname for the assembler in the first place.

jeff

Re: $tooldir

[Alexandre Oliva]

On Jan 31, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:

>   In message <orhftducc1.fsf@araguaia.dcc.unicamp.br>you write:
>> > Your suggested change would have the effect of overriding the configured
>> > assembler during bootstraps.

>> Wouldn't that be good?  Then, it would use the build-tooldir as even
>> though it was not installed it.  I agree that this might have other
>> unwanted side-effects, though.

> Well, I thought the whole idea of that built-in name was to override
> everything.  Maybe I misunderstood the original intentions of including
> a pathname for the assembler in the first place.

Yep, the original idea was that, but then I found out it was not such
a good idea because it was not possible to override the hard-coded
names, whereas it is possible to override any other hard-coded path.
Maybe assuming -B is supposed to override it is not a good idea, and
we should just add new flags to allow the user to specify the linker
and the assembler names.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: $tooldir

[Jeffrey A Law]

  In message < ork8y2cx7d.fsf@araguaia.dcc.unicamp.br >you write:
  > Yep, the original idea was that, but then I found out it was not such
  > a good idea
:-)  

  > because it was not possible to override the hard-coded
  > names, whereas it is possible to override any other hard-coded path.
  > Maybe assuming -B is supposed to override it is not a good idea, and
  > we should just add new flags to allow the user to specify the linker
  > and the assembler names.
I think I'd prefer -B to yet another option which is similar, but not quite
the same as some other option :-)

So, let's allow -B to override the absolute path.  Don't forget to mention
it somewhere in the docs though.

jeff

Re: $tooldir

[Alexandre Oliva]

On Feb  1, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:

>   In message < ork8y2cx7d.fsf@araguaia.dcc.unicamp.br >you write:
>> Yep, the original idea was that, but then I found out it was not such
>> a good idea
> :-)  

>> because it was not possible to override the hard-coded
>> names, whereas it is possible to override any other hard-coded path.
>> Maybe assuming -B is supposed to override it is not a good idea, and
>> we should just add new flags to allow the user to specify the linker
>> and the assembler names.
> I think I'd prefer -B to yet another option which is similar, but not quite
> the same as some other option :-)

> So, let's allow -B to override the absolute path.  Don't forget to mention
> it somewhere in the docs though.

Ok, I'll add this to my currently long and ever growing to-do list,
with very low priority.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: $tooldir

[Alexandre Oliva]

On Feb  1, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:

>   In message < ork8y2cx7d.fsf@araguaia.dcc.unicamp.br >you write:
>> Yep, the original idea was that, but then I found out it was not such
>> a good idea
> :-)  

>> because it was not possible to override the hard-coded
>> names, whereas it is possible to override any other hard-coded path.
>> Maybe assuming -B is supposed to override it is not a good idea, and
>> we should just add new flags to allow the user to specify the linker
>> and the assembler names.
> I think I'd prefer -B to yet another option which is similar, but not quite
> the same as some other option :-)

> So, let's allow -B to override the absolute path.  Don't forget to mention
> it somewhere in the docs though.

Ok, I'll add this to my currently long and ever growing to-do list,
with very low priority.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: $tooldir

[Jeffrey A Law]

  In message < ork8y2cx7d.fsf@araguaia.dcc.unicamp.br >you write:
  > Yep, the original idea was that, but then I found out it was not such
  > a good idea
:-)  

  > because it was not possible to override the hard-coded
  > names, whereas it is possible to override any other hard-coded path.
  > Maybe assuming -B is supposed to override it is not a good idea, and
  > we should just add new flags to allow the user to specify the linker
  > and the assembler names.
I think I'd prefer -B to yet another option which is similar, but not quite
the same as some other option :-)

So, let's allow -B to override the absolute path.  Don't forget to mention
it somewhere in the docs though.

jeff

Re: $tooldir

[Alexandre Oliva]

On Jan 31, 1999, Jeffrey A Law <law@upchuck.cygnus.com> wrote:

>   In message <orhftducc1.fsf@araguaia.dcc.unicamp.br>you write:
>> > Your suggested change would have the effect of overriding the configured
>> > assembler during bootstraps.

>> Wouldn't that be good?  Then, it would use the build-tooldir as even
>> though it was not installed it.  I agree that this might have other
>> unwanted side-effects, though.

> Well, I thought the whole idea of that built-in name was to override
> everything.  Maybe I misunderstood the original intentions of including
> a pathname for the assembler in the first place.

Yep, the original idea was that, but then I found out it was not such
a good idea because it was not possible to override the hard-coded
names, whereas it is possible to override any other hard-coded path.
Maybe assuming -B is supposed to override it is not a good idea, and
we should just add new flags to allow the user to specify the linker
and the assembler names.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: $tooldir

[Alexandre Oliva]

On Jan 26, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:

>   In message < orww2izgoa.fsf@araguaia.dcc.unicamp.br >you write:
>> The problem is that sometimes I'd like to try a new assembler or a new
>> linker, and I wouldn't like to have to rebuild gcc in order to try
>> them, and I don't want to install versions of as and ld that might
>> break egcs while other users are using it.
>> 
>> So I came up with the following idea: if any -Bdir argument is given,
>> gcc would search for as and ld in those directories before trying to
>> use the hard-coded pathnames.
>> 
>> Does this sound reasonable?
> Yes/no.  Part of me sez, if a path was spec'd at configure time, then it
> should override everything, even -B args.

> Your suggested change would have the effect of overriding the configured
> assembler during bootstraps.

Wouldn't that be good?  Then, it would use the build-tooldir as even
though it was not installed it.  I agree that this might have other
unwanted side-effects, though.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: $tooldir

[Jeffrey A Law]

  In message < orww2izgoa.fsf@araguaia.dcc.unicamp.br >you write:
  > The problem is that sometimes I'd like to try a new assembler or a new
  > linker, and I wouldn't like to have to rebuild gcc in order to try
  > them, and I don't want to install versions of as and ld that might
  > break egcs while other users are using it.
  > 
  > So I came up with the following idea: if any -Bdir argument is given,
  > gcc would search for as and ld in those directories before trying to
  > use the hard-coded pathnames.
  > 
  > Does this sound reasonable?
Yes/no.  Part of me sez, if a path was spec'd at configure time, then it
should override everything, even -B args.

Your suggested change would have the effect of overriding the configured
assembler during bootstraps.

jeff

Re: $tooldir

[Manfred Hollstein]

On nil, 20 January 1999, 02:55:49, oliva@dcc.unicamp.br wrote:

 > On Jan 19, 1999, Jeffrey A Law <law@hurl.cygnus.com> wrote:
 > 
 > > First requirement is we do not want to hose $tooldir uses in other Makefiles
 > > outside of gcc
 > 
 > > We also do not want to hose configurations which explicitly specify locations
 > > for tooldir or libsubdir.
 > 
 > > Am I missing any other issues?
 > 
 > Not that I can think of.  But you reminded me of a problem I've been
 > thinking of fixing for quite a long time, but that I haven't been able 
 > to pay attention to for quite a long time: --with-as and --with-ld
 > can be used to hard-code the pathnames of the assembler and the linker
 > into gcc and collect2.
 > 
 > The problem is that sometimes I'd like to try a new assembler or a new
 > linker, and I wouldn't like to have to rebuild gcc in order to try
 > them, and I don't want to install versions of as and ld that might
 > break egcs while other users are using it.
 > 
 > So I came up with the following idea: if any -Bdir argument is given,
 > gcc would search for as and ld in those directories before trying to
 > use the hard-coded pathnames.
 > 
 > Does this sound reasonable?

IMO, that's a good idea. But, shouldn't we (the collect2 program)
then treat "nm", "strip" (probably other programs) in a similar fashion?

 > 
 > -- 
 > Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
 > oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
 > Universidade Estadual de Campinas, SP, Brasil
 > 
 > 

manfred

Re: $tooldir

[Alexandre Oliva]

On Jan 20, 1999, Manfred Hollstein <manfred@s-direktnet.de> wrote:

>> So I came up with the following idea: if any -Bdir argument is given,
>> gcc would search for as and ld in those directories before trying to
>> use the hard-coded pathnames.

> IMO, that's a good idea. But, shouldn't we (the collect2 program)
> then treat "nm", "strip" (probably other programs) in a similar fashion?

Don't we?  I mean, do we currently hardcode the full pathnames of nm
and strip in collect2?

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: $tooldir

[Manfred Hollstein]

On nil, 20 January 1999, 10:16:36, oliva@dcc.unicamp.br wrote:

 > On Jan 20, 1999, Manfred Hollstein <manfred@s-direktnet.de> wrote:
 > 
 > >> So I came up with the following idea: if any -Bdir argument is given,
 > >> gcc would search for as and ld in those directories before trying to
 > >> use the hard-coded pathnames.
 > 
 > > IMO, that's a good idea. But, shouldn't we (the collect2 program)
 > > then treat "nm", "strip" (probably other programs) in a similar fashion?
 > 
 > Don't we?  I mean, do we currently hardcode the full pathnames of nm
 > and strip in collect2?

Oops, I just looked at the code in collect2.c.  Both programs (like "ldd"
and others, too) are looked for using an extended search mechanism.  If
"gcc" knows where its ${libsubdir} is, what its ${target_alias} is, it'll
pass some environment variables to collect2 initialized from those values.
Hence, it should work with "nm" and "strip", too.

Forget about my complaint.

manfred

Re: $tooldir

[Jeffrey A Law]

  In message < 13989.52523.298092.823253@sls5gj.stgl.sel.alcatel.de >you write:
  > On nil, 20 January 1999, 10:16:36, oliva@dcc.unicamp.br wrote:
  > 
  >  > On Jan 20, 1999, Manfred Hollstein <manfred@s-direktnet.de> wrote:
  >  > 
  >  > >> So I came up with the following idea: if any -Bdir argument is given,
  >  > >> gcc would search for as and ld in those directories before trying to
  >  > >> use the hard-coded pathnames.
  >  > 
  >  > > IMO, that's a good idea. But, shouldn't we (the collect2 program)
  >  > > then treat "nm", "strip" (probably other programs) in a similar fashio
  > n?
  >  > 
  >  > Don't we?  I mean, do we currently hardcode the full pathnames of nm
  >  > and strip in collect2?
  > 
  > Oops, I just looked at the code in collect2.c.  Both programs (like "ldd"
  > and others, too) are looked for using an extended search mechanism.  If
  > "gcc" knows where its ${libsubdir} is, what its ${target_alias} is, it'll
  > pass some environment variables to collect2 initialized from those values.
  > Hence, it should work with "nm" and "strip", too.
  > 
  > Forget about my complaint.
It's still a valid complaint in the sense that we want to be able to move the
whole toolchain and have collect2 do the right thing automatically.  That's
the  follow-on patch once we get $tooldir sorted out.  :-)  But we can't really
go anywhere until $tooldir is fixed.

jeff

Re: $tooldir

[Bill Currie]

[$tooldir discussion]

If gcc can get at it's spec file, why not code all the tool locations in
the spec file rather than the program?

I admit there's still the problem of locating the spec file, but at
least then there's only one file to search for.  Also, the spec file can
have search paths in it as well.
-- 
Leave others their otherness

Re: $tooldir

[Jeffrey A Law]

  In message < 36A6398F.3111C7E4@tssc.co.nz >you write:
  > [$tooldir discussion]
  > 
  > If gcc can get at it's spec file, why not code all the tool locations in
  > the spec file rather than the program?
Ewww.  Plus things can change dynamically.  The compiler still needs to work
if I (for example) delete "as" from the tooldir -- it would have to fall back
to its existing built-in search paths, and if those fail the user's path.

Certainly could be done, I don't see the benefit.

jeff

Re: $tooldir

[Bill Currie]

Jeffrey A Law wrote:
> 
>   In message <36A6398F.3111C7E4@tssc.co.nz>you write:
>   > [$tooldir discussion]
>   >
>   > If gcc can get at it's spec file, why not code all the tool locations in
>   > the spec file rather than the program?
> Ewww.  Plus things can change dynamically.  The compiler still needs to work
> if I (for example) delete "as" from the tooldir -- it would have to fall back
> to its existing built-in search paths, and if those fail the user's path.
> 
> Certainly could be done, I don't see the benefit.

Fair enough, it just occured to me while going over the other messages
and I was wandering if it had ever been considered.  As to the benifit?
Um, easy re-configurability of where to look for the other tools.

Also, isn't the spec file hard coded into gcc as a default and dumped
out for easy modification?  If the existing built-in search paths are
moved to the spec file, then you still have the same functionality as
before, just easily modified (and easily broken as well, I admit).

Bill
-- 
Leave others their otherness

Re: $tooldir

[Jeffrey A Law]

  In message < 36A68484.6633C9AF@tssc.co.nz >you write:
  > Fair enough, it just occured to me while going over the other messages
  > and I was wandering if it had ever been considered.  As to the benifit?
  > Um, easy re-configurability of where to look for the other tools.
It'll become quite easy once the tooldir change is made :-) 

Basically once everything is relative to a particular location, the rest
becomes relatively easy.


  > Also, isn't the spec file hard coded into gcc as a default and dumped
  > out for easy modification?  If the existing built-in search paths are
  > moved to the spec file, then you still have the same functionality as
  > before, just easily modified (and easily broken as well, I admit).
We really don't want folks hacking the spec files.

jeff

Re: $tooldir

[Jeffrey A Law]

  In message < 36A68484.6633C9AF@tssc.co.nz >you write:
  > Fair enough, it just occured to me while going over the other messages
  > and I was wandering if it had ever been considered.  As to the benifit?
  > Um, easy re-configurability of where to look for the other tools.
It'll become quite easy once the tooldir change is made :-) 

Basically once everything is relative to a particular location, the rest
becomes relatively easy.


  > Also, isn't the spec file hard coded into gcc as a default and dumped
  > out for easy modification?  If the existing built-in search paths are
  > moved to the spec file, then you still have the same functionality as
  > before, just easily modified (and easily broken as well, I admit).
We really don't want folks hacking the spec files.

jeff

Re: $tooldir

[Bill Currie]

Jeffrey A Law wrote:
> 
>   In message < 36A6398F.3111C7E4@tssc.co.nz >you write:
>   > [$tooldir discussion]
>   >
>   > If gcc can get at it's spec file, why not code all the tool locations in
>   > the spec file rather than the program?
> Ewww.  Plus things can change dynamically.  The compiler still needs to work
> if I (for example) delete "as" from the tooldir -- it would have to fall back
> to its existing built-in search paths, and if those fail the user's path.
> 
> Certainly could be done, I don't see the benefit.

Fair enough, it just occured to me while going over the other messages
and I was wandering if it had ever been considered.  As to the benifit?
Um, easy re-configurability of where to look for the other tools.

Also, isn't the spec file hard coded into gcc as a default and dumped
out for easy modification?  If the existing built-in search paths are
moved to the spec file, then you still have the same functionality as
before, just easily modified (and easily broken as well, I admit).

Bill
-- 
Leave others their otherness