This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Wrong as/ld picked by gcc configure


In article <20030314083923 dot A10125 at lucon dot org> you write:

>> > I believe the logic behind the gcc configure is flawed. Should it use
>> > the same approach as the gcc driver? If the gcc driver uses $PATH, why
>> > does the gcc configure do it differently? It doesn't make any senses
>> > to me.

>> The Fine Manual in gcc/doc/install.texi is extremely clear on what
>> happens when you do not tell configure exactly which as/ld to use.  It
>> explicitly says that it doesn't search $PATH (nor does the gcc driver
>> to my knowledge unless you go well out of your way to force it to do
>> so).  It explicitly says where it will search.  It explicitly says what
>> you should do if you don't like the default rules for a given system.

> The gcc driver calls pexecute which will use PATH unless MD_EXEC_PREFIX
> is defined. It has been this way for a long time. Did I miss something
> here?

When I set PATH=/foo, I can still run:

$ /full/path/gcc -v t.c

since all the paths for as/ld/collect2 were hard-coded into the
compiler driver/collect2.  Perhaps (mea culpa), that path hard-coding
only happens when one tells configure where to find the as/ld since I
now see that my RedHat box with the system compiler as built by RedHat
acts more like you seem to describe.  On the other hand, the FreeBSD
system compiler acts like I'd expect (hard-coded paths to all required
tools).  Well, if you don't like the logic, I'd say add the configure
flags to force the issue.  It is the only sane solution for people
that want repeatable setup and control.  The gcc installation manual
strongly implies that systems with more than one set of installed
ld/as or in non-standard locations should use this approach.

Ignore that advise at your peril.  No matter what patch you suggest to
gcc driver or configure logic, it will never be right for everyone, in
every case.  I'd favor stability of the current imperfect logic over
random tweaks that introduce yet more instability.

Regards,
Loren


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]