un/dosifyPath in SysTools.lhs bug?
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
./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
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: firstname.lastname@example.org
| On Behalf Of Dominic Cooney
| Sent: 14 April 2003 09:38
| To: email@example.com
| 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
| 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
| whatever calls it, might have a bug. From the comments of runSomething
| clear that it expects a 'native' program. Anyway, the problem can be
| by changing:
| cmd_line =3D pgm ++ ...
| 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
| -- fully convince myself that /cygdrive/ prefixes cannot
| -- really appear here.
| cygdrive_prefix =3D "/cygdrive/"
| | 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?
| 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