[Haskell-cafe] Re: Compilling GHC on Vista

Claus Reinke claus.reinke at talk21.com
Sat Apr 28 17:06:25 EDT 2007

that certainly looks somewhat confused. and the '/mingw/lib/crt2.o' at
the start of that ld call is going to be the first stumbling point. in any case,
that test result clearly puts the issue in gcc territory, i think.

with your PATH settings, i don't even see how you could be picking up
the cygwin ld instead of the mingw one, but the cygwin ld would not
know about those /mingw/... paths, whereas the mingw ld should look
them up from the root of the current drive. but if the right gcc, with the
right PATH, chooses the wrong ld, are the other internal gcc tools right?

more recent ghcs have a --with-ld=<path> option for configure, which
might help (was that in ghc-6.2?). also, gcc has a -Bprefix option, used
for invoking its internal programs, and apparently also for library paths,
and there are the GCC_EXEC_PREFIX, COMPILER_PATH, and
LIBRARY_PATH environment variables, with the same purpose.

but if i understood Simon correctly, gcc's paths handling is what is
causing this trouble. what does 'gcc -print-search-dirs' say? and, is
its output affected by those options or variables? for instance, does
'gcc -B C:/ -print-search-dirs' look any better?

as a hack, as long as gcc/ld look don't look in the right places, you
could try to make the places they look in the right ones. such as
mounting /mingw in cygwin, in the hope that even the wrong ld will
then be able to work with those mutilated paths..

but it does look as if gcc might need to be fixed for your system.
unfortunately, i can't seem to find any directly related ticket in the
gcc bug tracker (but then i don't search there often;-). it might be
easier to port the Haskell package that is holding you to 6.2.2
forward to recent ghc's (there are often compatibility packages
for apis that have changed, though not as often as one would like).

well, as you can see, i'm down to guessing on this one. good luck!-)
claus

ps. looking through your logs: why is HOME set to C:/ghc-6.2.2-src?
could there be any bashrc or other resource files in there affecting
the environment?

pps. ah, silly me. i finally understand that ghc ticket #1280 is not a
ghc issue at all. if gcc depends on that same call, it will not see the
mingw ld as executable, so might fall back on defaults later in the
PATH, right? but that would make me wonder how anyone could
have a vista build of ghc? perhaps they are using a newer mingw/gcc,
with some workaround for the issue? well, i'll stop guessing here.

> ld -Bdynamic /mingw/lib/crt2.o c:/MinGW/lib/gcc/mingw32/3.4.2/crtbegin.o -Lc:/M
> inGW/lib/gcc/mingw32/3.4.2 -Lc:/MinGW/lib/gcc -L/mingw/lib/gcc/mingw32/3.4.2 -Lc
> :/MinGW/mingw32/lib -L/mingw/mingw32/lib -L/mingw/lib -Lc:/MinGW/lib -L/mingw/li
> b ./ccaqcaaa.o -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32
> -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt c:/MinGW/lib
> /gcc/mingw32/3.4.2/crtend.o
> ld: /mingw/lib/crt2.o: No such file: No such file or directory
>
> It seems strange, because both C:\MinGW\bin and
> C:\MinGW\lib\gcc\mingw32\3.4.2 exist. Further, MingW and Cygwin are
> installed on the same driver.