This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
- From: "hjl dot tools at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Jun 2008 20:45:38 -0000
- Subject: [Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc
- References: <bug-36443-682@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #10 from hjl dot tools at gmail dot com 2008-06-08 20:45 -------
(In reply to comment #9)
> Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
> with unstalled gcc
>
> hjl dot tools at gmail dot com wrote:
>
> > How does gcc search the right paths when GCC_EXEC_PREFIX points
> > to non-existent directory because gcc isn't installed? Even if
> > there is a GCC_EXEC_PREFIX directory, it could be a very old
> > gcc installation and you may search very old files, instead of
> > the current ones, which are just built, but not installed yet.
>
> I don't remember all of the details of these changes.
>
> However, the compiler historically searched the configured libdir no
> matter what. This problem with having random old stuff in the place
> where you're going to be installing the new compiler is not new. People
> wanted that behavior for in-tree testing so that if you've already put a
> new libc in libdir the compiler you're testing can find it.
>
> 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"
>
Can't we at least test if $(libdir)/gcc/ exists before setting it
blindly?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443