------- Comment #12 from hjl dot tools at gmail dot com 2008-06-08 22:54
-------
(In reply to comment #11)
> Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
> with unstalled gcc
>
> hjl dot tools at gmail dot com wrote:
>
> >> I suspect that if you remove the setting in site.exp you will break the
> >> following scenario:
> >>
> >> 1. User puts libraries/headers in $pefix/{lib,include}
> >> 2. User builds GCC with corresponding --prefix option
> >> 3. User runs "make check"
Do you have an example to show it doesn't work if
GCC_EXEC_PREFIX isn't set. From what I can tell,
for most people, GCC_EXEC_PREFIX is equivalent to
unset since GCC_EXEC_PREFIX points to nowhere.
"make check" works for them, myself included. That
means that gcc testsuite can test uninstalled gcc
without setting GCC_EXEC_PREFIX. Isuggest we don't
set it and watch for fallout. We can investigate and
fix the problem when we get bug reports. Those bugs can
be assigned to me and I will fix them.
> >
> > Can't we at least test if $(libdir)/gcc/ exists before setting it
> > blindly?
>
> That seems like it might work.
>
> What is the effective default value of GCC_EXEC_PREFIX for the compiler
> being tested if we don't set the variable?
>
build_diretory/gcc/../lib/gcc/
which doesn't exist, at least for my build.
> Also, have you tested my suggested change to HOSTCC? If HOSTCC is
> another GCC then any environment variables that affect the compiler
> we're trying to test will also affect HOSTCC. It seems to me that the
> best way to avoid that causing problems is to make sure that HOSTCC
> sets/unsets the environment variables it needs.
>
That means we have to do it whenever HOSTCC is used, including new
and old tests. I don't think it is the right fix, given that no one
has shown GCC_EXEC_PREFIX really has to be set here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
