Actually I've pushed an updated patch to Cabal HEAD, so I'm hoping
someone will test & validate that on Windows. Though it needs to be
tested by someone who was having the problem because it does not happen
for everyone (for reasons that are not very clear).
See the earlier messages in this thread for more details. In brief, gcc
has default search paths that start with (1) "relative to gcc executable"
(this enables relocation of mingw), then has fallbacks like (2) "relative
to typical windows mingw install location" and (3) "relative to typical
unixish gcc install location".
The way ghc packages gcc effectively disables (1) while leaving
gcc open to picking up all kinds of unwanted versions that happen
to be around on the system. If you happen to have your own mingw
installed at c:/mingw, *and* you are building on drive c:, then you
may be lucky because (2) is specified as "/mingw" (which is interpreted
as <current drive>:/mingw, so it works when you're on c:, not if
you're on d:, z:, ..).
Of course, this luck depends on the ghc gcc and the local mingw
being compatible, else you'll get other issues; and if msys or cygwin
have /mingw mounted as something else, or if other headers/tools
are picked up via (3), you'll get still other issues, and possibly
different ones, depending on whether you're using msys or cygwin..
Looking forward to that patch, though I'd still like ghc to preserve
its internal gcc's directory layout, so that ghc's gcc works like any
other gcc.
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
