Snapshot gcc-4.3-20100228 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100228/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
While looking at PR42308 and trying to understand why the make check
is leaky and starts to call the system compiler instead of the xgcc during
a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I noticed
that we seem to build libiberty both at the toplevel and within the multil
Jack Howarth writes:
>While looking at PR42308 and trying to understand why the make check
> is leaky and starts to call the system compiler instead of the xgcc during
> a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I noticed
> that we seem to build libiberty both at the
On Mon, 1 Mar 2010, Andreas Schwab wrote:
> Jack Howarth writes:
>
> >While looking at PR42308 and trying to understand why the make check
> > is leaky and starts to call the system compiler instead of the xgcc during
> > a make check on either x86_64-apple-darwin9 or i686-apple-darwin10, I
On Mon, Mar 01, 2010 at 02:31:52AM +0100, Andreas Schwab wrote:
> Jack Howarth writes:
>
> >While looking at PR42308 and trying to understand why the make check
> > is leaky and starts to call the system compiler instead of the xgcc during
> > a make check on either x86_64-apple-darwin9 or i6
On Mon, 1 Mar 2010, Jack Howarth wrote:
> Somehow the recursive make is broken for libiberty and is silently using
> the system compiler.
> Jack
I believe this is PR29404. IIRC, in addition to libiberty, other
recursive "make check"s fail too due to using the system (stage1)
compil
