filepath mangling under Windows?
With ghc-5.02.2 running from a Makefile in a cygwin shell under Windows XP, the following behaviour occurs: ghc -package lang -package posix -c -o /d/haskell/hmake-3.00/targets/ix86-CYGWIN_NT-5.1/obj/hmake/QSort.o QSort.hs Assembler messages: FATAL: Can't create \d\haskell\hmake-3.00\targets\ix86-CYGWIN_NT-5.1\obj\hmake\QSort.o: No such file or directory It looks like ghc has reversed the slashes in the filepath given to the -o option, and this is the reason the assembler fails. The directory certainly exists, but we suspect cygwin only understands the forward-slash form not the backward-slash form. Is this a bug in ghc? Or is there some option we can give to persuade ghc not to reverse the slashes? Regards, Malcolm
ghc-5.02.2 is not a cygwin application, so it won't
understand paths like /d/foo -- it will understand
d:/foo and d:\foo though.
Internally, the compiler will canonicalise paths to
'platform-native' formats before passing them to
external tools, which is why you see the slashes
reversed. GHC could with benefit do some
verification of -o paths, to avoid the cryptic msg
you're seeing -- I'll add it to my ToDo list.
hth
--sigbjorn
----- Original Message -----
From: "Malcolm Wallace"
With ghc-5.02.2 running from a Makefile in a cygwin shell under Windows XP, the following behaviour occurs:
ghc -package lang -package posix -c -o /d/haskell/hmake-3.00/targets/ix86-CYGWIN_NT-5.1/obj/hmake/QSort.o QSort.hs Assembler messages: FATAL: Can't create
\d\haskell\hmake-3.00\targets\ix86-CYGWIN_NT-5.1\obj\hmake\QSort.o:
No such file or directory
It looks like ghc has reversed the slashes in the filepath given to the -o option, and this is the reason the assembler fails. The directory certainly exists, but we suspect cygwin only understands the forward-slash form not the backward-slash form.
Is this a bug in ghc? Or is there some option we can give to persuade ghc not to reverse the slashes?
Regards, Malcolm
ghc-5.02.2 is not a cygwin application,
Whilst I was aware that GHC no longer requires Cygwin to run, I didn't realise that it actively discourages use under Cygwin. This issue arose because a Windows user would like to use `hmake' with GHC, and the `hmake' installation currently requires Cygwin. Is there really no possibility of using GHC in the Cygwin environment?
so it won't understand paths like /d/foo -- it will understand d:/foo and d:\foo though.
Internally, the compiler will canonicalise paths to 'platform-native' formats before passing them to external tools, which is why you see the slashes reversed.
As far as I understand the Windows filesystem (which I admit is not very far at all), \d\foo is not a canonical pathname, so why is GHC generating it? Thanks for looking into these issues, Sigbjorn. Regards, Malcolm
ghc-5.02.2 is not a cygwin application,
Whilst I was aware that GHC no longer requires Cygwin to run, I didn't realise that it actively discourages use under Cygwin. This issue arose because a Windows user would like to use `hmake' with GHC, and the `hmake' installation currently requires Cygwin. Is there really no possibility of using GHC in the Cygwin environment?
Don't know where you get this "actively discouraging" bit from. You make it sound as if it isn't possible, which certainly isn't the case - you just have to keep in mind that using filepaths that only makes sense wrt. the Cygwin mount table is not a Good Idea, i.e., stuff like /cygdrive/d/foo. (Have a look at the 'cygpath' utility, btw). If you're really that gung-ho about cygwin, you could always compile up GHC using the cygwin toolchain.
Internally, the compiler will canonicalise paths to 'platform-native' formats before passing them to external tools, which is why you see the slashes reversed.
As far as I understand the Windows filesystem (which I admit is not very far at all), \d\foo is not a canonical pathname, so why is GHC generating it?
Because you said /d/foo , which it translated to \d\foo before feeding ut to 'as' (canonical == canonical slashes), which is another non-cygwin application (i.e., we include cygwin-free versions of gcc, as and ld with the ghc installer). --sigbjorn
ghc-5.02.2 is not a cygwin application,
Whilst I was aware that GHC no longer requires Cygwin to run, I didn't realise that it actively discourages use under Cygwin.
Don't know where you get this "actively discouraging" bit from.
I'm sorry, I just meant that it seems to be a little bit more difficult now to get GHC and Cygwin to interoperate than it once was. The situation as I understand it is this: * A user has Cygwin as a preferred environment under Windows. * This user has D:\ mounted in Cygwin as /d/. * Most of the user's applications are found in the path /d/. * But a pre-built GHC does not understand the /d/ paths. * The user has tried changing their Cygwin environment to use D:\ instead of /d/. * Now GHC understands paths properly, but most of his other applications now do not work because of the opposite path issue. What I'm wondering is whether the difficulty is a necessary one, or if it was unintentional, is there an easy fix? From your suggestions, I guess there isn't an easy fix.
You make it sound as if it isn't possible, which certainly isn't the case - you just have to keep in mind that using filepaths that only makes sense wrt. the Cygwin mount table is not a Good Idea, i.e., stuff like /cygdrive/d/foo. (Have a look at the 'cygpath' utility, btw).
I have already suggested `cygpath' to the user, which is rather ugly but does at least work. One issue for me however, as a distributor of Haskell software, is that I don't want to pollute the installation Makefiles with lots of `cygpath' stuff that is only applicable to one platform. Maybe I can find a relatively painless way to propagate the cygpath calls through a Makefile hierarchy at configure time.
If you're really that gung-ho about cygwin, you could always compile up GHC using the cygwin toolchain.
I avoid Windows altogether myself, but I'll suggest it to the user who had the original complaint. Regards, Malcolm
"Malcolm Wallace"
...
Don't know where you get this "actively discouraging" bit from.
I'm sorry, I just meant that it seems to be a little bit more difficult now to get GHC and Cygwin to interoperate than it once was. The situation as I understand it is this:
* A user has Cygwin as a preferred environment under Windows. * This user has D:\ mounted in Cygwin as /d/. * Most of the user's applications are found in the path /d/. * But a pre-built GHC does not understand the /d/ paths. * The user has tried changing their Cygwin environment to use D:\ instead of /d/. * Now GHC understands paths properly, but most of his other applications now do not work because of the opposite path issue.
What I'm wondering is whether the difficulty is a necessary one, or if it was unintentional, is there an easy fix? From your suggestions, I guess there isn't an easy fix.
Right, somehow re-implementing cygwin's open() doesn't sound wise. I don't understand why feeding GHC d:/foo rather than /d/foo has such global ramifications for the user in Q. --sigbjorn
Hi all.
What I'm wondering is whether the difficulty is a necessary one, or if it was unintentional, is there an easy fix? From your suggestions, I guess there isn't an easy fix.
I haven't tried this with GHC yet but Earnie Boyd on Sourceforge has recently forked Cygwin to produce a Mingw32 build environment called MSYS. This environment uses the same native Mingw32 gcc as distributed with GHC and is designed to allow the use of native Windows tools within a GNU autotools configuration/build environment. MSYS converts native paths into Posix while executing processes (including Cygwin soft links) and may help your user, Malcolm, to build under Windows while retaining the benefits of a GNU Posix work environment - Makefiles etc. In contrast to Cygwin, executables produced under MSYS are completely normal native Win32 programs (as produced by Mingw32). Most importantly, they depend only on MS Win32 libraries - not on cygwin1.dll or other Posix emulation libraries.
You make it sound as if it isn't possible, which certainly isn't the case - you just have to keep in mind that using filepaths that only makes sense wrt. the Cygwin mount table is not a Good Idea, i.e., stuff like /cygdrive/d/foo. (Have a look at the 'cygpath' utility, btw).
I have already suggested `cygpath' to the user, which is rather ugly but does at least work. One issue for me however, as a distributor of Haskell software, is that I don't want to pollute the installation Makefiles with lots of `cygpath' stuff that is only applicable to one platform. Maybe I can find a relatively painless way to propagate the cygpath calls through a Makefile hierarchy at configure time.
If you're really that gung-ho about cygwin, you could always compile up GHC using the cygwin toolchain.
I avoid Windows altogether myself, but I'll suggest it to the user who had the original complaint.
This is why no-one uses Haskell. (Ooops :)) Cheers Mike Thomas.
participants (3)
-
Malcolm Wallace -
Mike Thomas -
Sigbjorn Finne