This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Possible GCC 4.3 driver regression caused by your patch
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Greg Schafer <gschafer at zip dot com dot au>
- Cc: Carlos O'Donell <carlos at codesourcery dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 3 Mar 2008 08:11:30 -0500 (EST)
- Subject: Re: Possible GCC 4.3 driver regression caused by your patch
- References: <20080301225746.GA25180@eyo32.local>
On Sun, 2 Mar 2008, Greg Schafer wrote:
> Hi Carlos and Mark,
>
> Your "Relocated compiler should not look in $prefix" patch here:
>
> http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
>
> appears to have caused a regression in my GCC 4.3 testing.
So *now* I know why my cross-test setup to (non-sysrooted)
cris-axis-linux-gnu have trouble finding startfiles and
pre-installed include files! Thanks! It seems Carlos' fix for
the testsuite, has some flaw I'll look into. At the very least,
cutnpasting commands from the dejagnu .log files don't work;
there's some environment variable (more than just
GCC_EXEC_PREFIX, AFAICT). And some testsuites (forgot, maybe it
was libgomp?) need to be adjusted too.
> In summary, there is a small window *during the GCC build itself* where GCC
> does not pick up the correct startfiles. For example, when GCC_FOR_TARGET is
> called to build the target libraries, the startfiles in $prefix/lib are not
> used. Instead, the startfiles from the host's /usr/lib are used which breaks
> my build. Note that the problem seems to rectify itself once the just-built
> GCC is installed into $prefix.
That's a problem. Maybe it can be fixed by the build machinery
e.g. setting GCC_EXEC_PREFIX and friends at the time. I don't
think gcc fallback-peeking into the base --prefix= tree (unless
specifically told) is the solution.
brgds, H-P