un/dosifyPath in SysTools.lhs bug?

Simon Peyton-Jones simonpj@microsoft.com
Mon, 14 Apr 2003 13:51:30 +0100

Turns out that I've already updated the documentation; it's just that it
hasn't made it into a released version yet. (Update was on 17 Feb 2003.)
See the except below.

After <command>autoconf</command> run <command>./configure</command> in
<filename>fptools/</filename> thus:

  ./configure --host=3Di386-unknown-mingw32 =
This is the point at which you specify that you are building GHC-mingw
(see <xref linkend=3D"ghc-mingw">). </para>

<para> Both these options are important! It's possible to get into
trouble using the wrong C compiler!
Furthermore, it's very important that you specify a=20
full mingw path for <command>gcc</command>, not a cygwin path, because
GHC (which
uses this path to invoke <command>gcc</command>) is a Mingw program and
understand a cygwin path..  For example, if you=20
say <literal>--with-gcc=3D/mingw/bin/gcc</literal>, it'll be interpreted
<filename>/cygdrive/c/mingw/bin/gcc</filename>, and GHC will fail the
time it tries to invoke it.   (Worse, the failure does not come with
a helpful error message, unfortunately.)

| -----Original Message-----
| From: glasgow-haskell-users-admin@haskell.org
| On Behalf Of Dominic Cooney
| Sent: 14 April 2003 09:38
| To: glasgow-haskell-users@haskell.org
| I'm trying to build ghc (the 5.04.3 source tarball) on Windows, but
| after the ghc-inplace is written and is used to build something, ghc
| If I cut and paste the command* and run it with -v, it's evident that
ghc is
| trying to execute /cygdrive/c/mingw/bin/gcc, which is the gcc that I
| ./configured --with-gcc.
| But ghc is a mingw executable! So I think runSomething in
SysTools.lhs, or
| whatever calls it, might have a bug. From the comments of runSomething
it is
| clear that it expects a 'native' program. Anyway, the problem can be
| by changing:
| cmd_line =3D pgm ++ ...
| to:
| cmd_line =3D (dosifyPath pgm) ++ ...
| And dosifyPath and undosifyPath (#if defined(mingw32_HOST_OS)) have no
| regard for drive letters! Shouldn't they be something like:
| unDosifyPath xs =3D
| 	case (subst '\\' '/' xs) of
| 		drive : ':' : rest -> "/cygdrive/" ++ (drive : rest)
| 		xs'			 -> xs'
| dosifyPath stuff
|   =3D subst '/' '\\' real_stuff
|  where
|    -- fully convince myself that /cygdrive/ prefixes cannot
|    -- really appear here.
|   cygdrive_prefix =3D "/cygdrive/"
|   real_stuff
|     | cygdrive_prefix `isPrefixOf` stuff =3D
| 		case (dropList cygdrive_prefix stuff) of
| 			drive : rest -> drive : ':' : rest
|     | otherwise =3D stuff
| That comment re: cygdrive in dosifyPath is rather ominous... but those
| changes at least allow ghc-inplace to start compiling the next
| The build then barfed in rts doing:
| ../../ghc/compiler/ghc-inplace -O2 -package-name rts -O -Rghc-timing
| Exception.hc -o Exception.o
| Because Exception.hc couldn't #include "Stg.h"; it seems the GHC
| path was specified as a couple of Options instead of a single
| which meant showOptions didn't dosify it.
| Doing a quick hack in showOptions to peek at Options for the
| prefix keeps the build going. What I'm wondering is:
| Is anyone building GHC on Windows, and if so, how do you do it?
| Thanks,
| Dominic Cooney
| * The command is:
| ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O -optc-Wall
| -optc-Wstrict-prototypes -optc-Wmissing-prototypes
| -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
| -optc-Wbad-function-cast -optc-Wcast-align -optc-I../includes -optc-I.
| -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer
| -optc-DDLLized -O2 -package-name rts -O -Rghc-timing  -hisuf dll_hi
| dll_hc -osuf dll_o    -c Main.c -o Main.dll_o
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users