Re: [Mingw-users] cc1 not found

[Keith M. <kei...@us...>]

On Monday 02 April 2007 11:44, ra...@ed... wrote:
> > Chris issued new runtime and w32api packages early last week; AFAIK
> > those captured Danny's patch set to fix this problem. =A0I'd kind of
> > assumed you were referring to a remaining bug *after* you'd
> > installed those; if that is the case, then yes, a follow-up bug
> > report would be in order; if not, then it isn't necessary.
>
> I assumed that one needs to rebuild the compiler itself to get things
> fixed. There was a new gcc posted to the mailing list, but other
> compiler (especially g++) still have the problem.

It seems that may be the case, yes.

> Thus I recently=20
> asked you to rebuild the g++ compiler...

Sure, I'll do that, and you can all ditch the Win32 crap, and move to a=20
real OS, for I'll be building a GNU/Linux hosted MinGW cross :-)  But=20
seriously...

> but did not get an answer :-/=20

IIRC, you asked if my cross-compiler build scripts could be used for a=20
native build, and I still owe you an answer.  Sorry, your question was=20
buried in a closed thread, and it slipped my mind.

All my development work for the project is accomplished on a GNU/Linux=20
host, and my scripts are designed for building a cross-hosted MinGW=20
compiler suite, running on that host, and targetting Win32.  I've never=20
built a MinGW compiler on a native host, so I don't know what issues=20
you would face, if you tried that.  One that does spring to mind is=20
that I install to $HOME/mingw, and set both the --prefix and the=20
=2D-with-sysroot options to that path.  Although a standard MinGW install=20
doesn't use either /usr or /usr/local, the GCC build needs to find both=20
$SYSROOT/usr and $SYSROOT/usr/local, or the build fails.  Building=20
without a $SYSROOT isn't an option for a cross build--the compiler does=20
build, but it doesn't work properly; I resolved, or rather I worked=20
around, the issue by creating two symlinks in $HOME/mingw

  ( cd $HOME/mingw && { ln -s . usr; ln -s . local; } )

which makes those two required directories appear to exist, and to=20
contain the required installed components, as they are installed into=20
$HOME/mingw.  You can't use this trick, on native Win32, because it=20
doesn't support symlinks.

If I were building natively, I should use Danny's script, which IIRC, he=20
posts on the download site, alongside his released builds.

> Thus I did not installed the new above packages.

Installing them surely wouldn't hurt, and would take you part of the way=20
to fixing the problem; it would also provide the infrastructure to=20
allow you to try to rebuild the toolchain yourself, in the absence of a=20
build provided by others.

> Are you sure, that=20
> installing the new runtime and w32api packages would also fix the
> compiler?

No, apparently it is not, since...

Dave Murphy wrote:
> Keith, these packages are only part of the solution - the toolchain=20
> needs [to be] rebuilt with these packages installed for a complete
> fix.=20

Regards,
Keith.