Re: Wrong as/ld picked by gcc configure

["H. J. Lu" <hjl at lucon dot org>]

On Fri, Mar 14, 2003 at 11:26:23AM -0600, Loren James Rittle wrote:
> 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.
> 

All I said was the gcc configure should match the gcc driver. If as/ld
is hardcoded in the gcc driver, the gcc configure should do the same,
which I see the current gcc driver try to do:

        if test x$host = x$target; then
            test_dirs="$test_dirs \
                   /usr/libexec \
                   /usr/ccs/gcc \
                   /usr/ccs/bin \
                   /udk/usr/ccs/bin \
                   /bsd43/usr/lib/cmplrs/cc \
                   /usr/cross64/usr/bin \
                   /usr/lib/cmplrs/cc \
                   /sysv/usr/lib/cmplrs/cc \
                   /svr4/usr/lib/cmplrs/cc \
                   /usr/bin"
        fi

Does your BSD hardcode as/ld in one of those directories? What I want
is the gcc configure should follow PATH like the gcc driver. Did I ask
too much?


H.J.