Re: [nhc-bugs] Building nhc98 on Windows 2000
I got curious, so I went to have a look at the nhc-bugs archives -- seems like what's at the root of it all is that the following ghc invocation:
ghc -package lang -package posix -c \ -o /tmp/nhc98-1.12/targets/ix86-CYGWIN_NT-5.0/obj/hmake/QSort.o \ QSort.hs
Assembler messages: FATAL: Can't create \ \tmp\nhc98-1.12\targets\ix86-CYGWIN_NT-5.0\obj\hmake\QSort.o
This is a known 'usability bug' with GHC - it doesn't check that the directory portion of the '-o' file exists, but just merrily hands it off to the assembler, which barfs with the above unfriendly message.
So, for whatever reason, that /tmp/... directory doesn't exist.
Question: which assembler is being called there? In a standalone GHC, that can't be the cygwin assembler, so, unless the call is routed via the cygwin shell, the assembler is unlikely to know about cygwin's file system. When I encountered that problem, a simple fix was to add the necessary prefix to turn the cygwin path into a native path: c:/cygwin/tmp/nhc... neither GHC nor cygwin have trouble with that path, and the assembler was happy as well. Claus
"C.Reinke"
Assembler messages: FATAL: Can't create \ \tmp\nhc98-1.12\targets\ix86-CYGWIN_NT-5.0\obj\hmake\QSort.o
This is a known 'usability bug' with GHC - it doesn't check that the directory portion of the '-o' file exists, but just merrily hands it off to the assembler, which barfs with the above unfriendly message.
So, for whatever reason, that /tmp/... directory doesn't exist.
Question: which assembler is being called there?
The one GHC comes with, i.e., one that's from the mingw distribution (=> is itself free of cygwin.)
In a standalone GHC, that can't be the cygwin assembler, so, unless the call is routed via the cygwin shell, the assembler is unlikely to know about cygwin's file system.
Quite so.
When I encountered that problem, a simple fix was to add the necessary prefix to turn the cygwin path into a native path:
c:/cygwin/tmp/nhc...
neither GHC nor cygwin have trouble with that path, and the assembler was happy as well.
That'll work, or just create a toplevel /tmp -- I always seem to end up doing so. So, provided nhc98 can avoid depending on 'posix', don't just give up on using GHC for compiling nhc98 under win32 just yet. --sigbjorn
participants (2)
-
C.Reinke -
Sigbjorn Finne