- Glasgow-haskell-users

RE: un/dosifyPath in SysTools.lhs bug?
by Simon Peyton-Jones 14 Apr '03

14 Apr '03

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: <Screen> ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc </Screen> This is the point at which you specify that you are building GHC-mingw (see <xref linkend="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 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 won't understand a cygwin path.. For example, if you say <literal>--with-gcc=/mingw/bin/gcc</literal>, it'll be interpreted as <filename>/cygdrive/c/mingw/bin/gcc</filename>, and GHC will fail the first time it tries to invoke it. (Worse, the failure does not come with a helpful error message, unfortunately.) </para> | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Dominic Cooney | Sent: 14 April 2003 09:38 | To: glasgow-haskell-users(a)haskell.org | | I'm trying to build ghc (the 5.04.3 source tarball) on Windows, but right | after the ghc-inplace is written and is used to build something, ghc fails. | 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 fixed | by changing: | | cmd_line = pgm ++ ... | | to: | | cmd_line = (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 = | case (subst '\\' '/' xs) of | drive : ':' : rest -> "/cygdrive/" ++ (drive : rest) | xs' -> xs' | | dosifyPath stuff | = subst '/' '\\' real_stuff | where | -- fully convince myself that /cygdrive/ prefixes cannot | -- really appear here. | cygdrive_prefix = "/cygdrive/" | | real_stuff | | cygdrive_prefix `isPrefixOf` stuff = | case (dropList cygdrive_prefix stuff) of | drive : rest -> drive : ':' : rest | | otherwise = stuff | | That comment re: cygdrive in dosifyPath is rather ominous... but those | changes at least allow ghc-inplace to start compiling the next thing... | | The build then barfed in rts doing: | | ../../ghc/compiler/ghc-inplace -O2 -package-name rts -O -Rghc-timing -c | Exception.hc -o Exception.o | | Because Exception.hc couldn't #include "Stg.h"; it seems the GHC include | path was specified as a couple of Options instead of a single FileOption, | which meant showOptions didn't dosify it. | | Doing a quick hack in showOptions to peek at Options for the /cygdrive/ | 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-W | -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 -hcsuf | dll_hc -osuf dll_o -c Main.c -o Main.dll_o | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: un/dosifyPath in SysTools.lhs bug?
by Simon Peyton-Jones 14 Apr '03

14 Apr '03

I always configure with --with-gcc=c:/mingw/bin/gcc and everything is fine. I see that the Building Guide suggests --with-gcc=/mingw/bin/gcc which I suspect is plain wrong. Try with the path syntax I use, and see if that helps. Meanwhile I'll modify the building guide. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users-admin@haskell.org] | On Behalf Of Dominic Cooney | Sent: 14 April 2003 09:38 | To: glasgow-haskell-users(a)haskell.org | | I'm trying to build ghc (the 5.04.3 source tarball) on Windows, but right | after the ghc-inplace is written and is used to build something, ghc fails. | 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 fixed | by changing: | | cmd_line = pgm ++ ... | | to: | | cmd_line = (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 = | case (subst '\\' '/' xs) of | drive : ':' : rest -> "/cygdrive/" ++ (drive : rest) | xs' -> xs' | | dosifyPath stuff | = subst '/' '\\' real_stuff | where | -- fully convince myself that /cygdrive/ prefixes cannot | -- really appear here. | cygdrive_prefix = "/cygdrive/" | | real_stuff | | cygdrive_prefix `isPrefixOf` stuff = | case (dropList cygdrive_prefix stuff) of | drive : rest -> drive : ':' : rest | | otherwise = stuff | | That comment re: cygdrive in dosifyPath is rather ominous... but those | changes at least allow ghc-inplace to start compiling the next thing... | | The build then barfed in rts doing: | | ../../ghc/compiler/ghc-inplace -O2 -package-name rts -O -Rghc-timing -c | Exception.hc -o Exception.o | | Because Exception.hc couldn't #include "Stg.h"; it seems the GHC include | path was specified as a couple of Options instead of a single FileOption, | which meant showOptions didn't dosify it. | | Doing a quick hack in showOptions to peek at Options for the /cygdrive/ | 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-W | -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 -hcsuf | dll_hc -osuf dll_o -c Main.c -o Main.dll_o | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: un/dosifyPath in SysTools.lhs bug?
by Simon Marlow 14 Apr '03

14 Apr '03

> I'm trying to build ghc (the 5.04.3 source tarball) on > Windows, but right > after the ghc-inplace is written and is used to build > something, ghc fails. > 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. I think we usually use a DOS-style path when specifying --with-gcc, which avoids this problem. I'll let someone more windows-savvy answer your other questions... Cheers, Simon

1 0

un/dosifyPath in SysTools.lhs bug?
by Dominic Cooney 14 Apr '03

14 Apr '03

I'm trying to build ghc (the 5.04.3 source tarball) on Windows, but right after the ghc-inplace is written and is used to build something, ghc fails. 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 fixed by changing: cmd_line = pgm ++ ... to: cmd_line = (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 = case (subst '\\' '/' xs) of drive : ':' : rest -> "/cygdrive/" ++ (drive : rest) xs' -> xs' dosifyPath stuff = subst '/' '\\' real_stuff where -- fully convince myself that /cygdrive/ prefixes cannot -- really appear here. cygdrive_prefix = "/cygdrive/" real_stuff | cygdrive_prefix `isPrefixOf` stuff = case (dropList cygdrive_prefix stuff) of drive : rest -> drive : ':' : rest | otherwise = stuff That comment re: cygdrive in dosifyPath is rather ominous... but those changes at least allow ghc-inplace to start compiling the next thing... The build then barfed in rts doing: ../../ghc/compiler/ghc-inplace -O2 -package-name rts -O -Rghc-timing -c Exception.hc -o Exception.o Because Exception.hc couldn't #include "Stg.h"; it seems the GHC include path was specified as a couple of Options instead of a single FileOption, which meant showOptions didn't dosify it. Doing a quick hack in showOptions to peek at Options for the /cygdrive/ 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-W -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 -hcsuf dll_hc -osuf dll_o -c Main.c -o Main.dll_o

1 0

Posix.createPipe failing
by Hal Daume III 13 Apr '03

13 Apr '03

After running a few hundred createPipe's, they begin to fail for me, giving the error: Fail: system error Action: createPipe This seems to me to be like the "not enough file handles" error you get when using lazy readFile, since this doesn't close the handle soon enough. Am I correct in this intuition and if I am (or otherwise), how do I fix it? Thanks! - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

2 1

Re: Help Creating Libraries
by Dominic Steinitz 12 Apr '03

12 Apr '03

I've tried building the libraries tree but got the following. Can anyone help? I'm not sure what name to give the proposed crypto library. Should it be Data.Crypto? [dom@tility libraries]$ make boot ------------------------------------------------------------------------ ===fptools== Recursively making `boot' in base haskell98 network haskell-src ... PWD = /home/dom/fptools/libraries ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make boot -r; in /home/dom/fptools/libraries/base ------------------------------------------------------------------------ make[1]: *** No rule to make target `/prelude/primops.txt', needed by `GHC/PrimopWrappers.hs'. Stop. make: *** [boot] Error 1 [dom@tility libraries]$ Dominic Steinitz ----- Original Message ----- From: "Simon Marlow" <simonmar(a)microsoft.com> To: "Simon Peyton-Jones" <simonpj(a)microsoft.com>; "Dominic Steinitz" <dominic.steinitz(a)blueyonder.co.uk> Sent: Friday, April 11, 2003 10:48 AM Subject: RE: Help Creating Libraries Hi Dominic, There are two ways to add libraries: do it directly in a GHC tree using our build infrastructure, or try to do it on your own. We tried to get some interest going in developing a separate build infrastructure for people in your position (see discussions on the GHC lists), but that effort seems to be stalled. Cheers, Simon > -----Original Message----- > From: Simon Peyton-Jones > Sent: 07 April 2003 08:51 > To: Dominic Steinitz; Simon Marlow > Cc: Simon Peyton-Jones > > Dominic > > Excellent! Simon is the library king, but he's away today. > I think it goes like this: you agree with Simon (and > preferably the libraries(a)haskell.org) libraries list what the > name and signature of your module will be. We give you CVS > access. You check out the libraries tree (no need to build > GHC if you don't want to) and add your library. With Haddock > documentation. That's it. > > But it ought to be documented -- then more people might do it! > > Simon > > | -----Original Message----- > | From: Dominic Steinitz [mailto:dominic.steinitz@blueyonder.co.uk] > | Sent: 06 April 2003 17:09 > | To: Simon Peyton-Jones; Simon Marlow > | > | Simon & Simon, > | > | I'd quite like to create a crypto library. There are some > modules already > | scattered around the place: md5, sha1, des and rsa. I've > just added cipher > | block chaining mode to the existing des module. > | > | I'd be grateful for any advice on how to set about creating > a library. Do I > | have to check out the ghc source from CVS and build it and > somehow add an > | extra library? Is there a document describing how to do it? > Should I be > | asking this question on the libraries mailing list? > | > | Dominic Steinitz > | > >

1 0

Setting "-package-conf" via environment variable?
by Peter Simons 12 Apr '03

12 Apr '03

Hi, is there any way to provide GHC with a value for "-package-conf" via an environment variable? I'd like to tell it to use a local package config file in addition to it's own, but I'd like GHC to find that "automatically". The users of the installation system should not have to know about this. Any help is appreciated. Peter

1 0

BU FIRSATTAN RARARLANIN.
by MARAMARA Erotik Market 12 Apr '03

12 Apr '03

DIKKAT VIDEO CD : Iddia ediyoruz.. Hic bir yerden temin edemeyeceginiz ses ve g�runtu kalitesi ile yuzlerce porno video CD. arSivimiz yenilenmistir. istemis oldugunuz video CD.ler bire bir yollanir kesinlikle isteginiz harici alakasiz baSka video CD.ler yollanmaz. Anal. Oral. Vajinal. Grup. Zenci. FethiS. Ayak fethiS. Gay. Zenci gay. Trans. Transexual. Lezbiyen ve daha bircok ceSit .... <http://www.erotik.sites.cc/> ZENGIN URUN CESITLERIMIZ : Sisme Bebekler ..... (Erkek & Bayan) Kesinlikle size hayir demeyecek. Vibrat�rler ........ Istediginiz boy ve ebatlarda (Vajinal/Anal/catal.Pilli.Motorlu.TitreSimli) Suni Vajinalar ..... Asla gerceginden ayirt edemeyeceksiniz (Gercek ten hassasiyetinde) Reailistik Penisler. Gercek ten hassasiyetinde ve dokusunda (Vantuzlu/Deri kemer kilotlu) Vakum Pompalari .... Ereksiyonu kolaylastirici ve duzenli kullanimlarda peniste irilesme saglar. Geciktiriciler ..... Erken boSalmayi dert etmeyin (Sprey ceSitleri/Kremler) Kremler ............ Anal ve Vajinal iliSkilerde kullanabileceginiz kayganlaStirici krem ceSitleri Uyandiricilar ...... Cinsel istek uyandirici haplar ve damlalar. Yapmaniz gereken tek Sey <http://www.erotik.sites.cc/> TIKLAMAK .. NOT : BU MAIL REKLAM AMAcLI OLUP HIcBIR SEKILDE TARAFIMIZDA KAYDINIZ BULUNMAMAKTADIR. ILGI ALANINIZIN DISINDA ISE EGER LUTFEN DIKKATE ALMAYINIZ TESEKKURLER..

1 0

GHC running on powerpc-unknown-linux!
by Sven Moritz Hallberg 12 Apr '03

12 Apr '03

Greetings! Finally, I have the honor to report my success in bootstrapping an unregisterised incarnation of the Glorious Glasgow Haskell Compilation System version 5.04.3 on my PowerBook G4 running Gentoo Linux! Unfortunately I have not been able to bring to life the dynamic linker due to relocation troubles... Anyone familiar with ELF relocations on PowerPC Linux (i.e. as described in the System V ABI PowerPC Supplement) feel free to have a look at do_Elf_Rela_relocations() in ghc/rts/Linker.c! Shae Erisson generously lent me some webspace at http://shapr.homelinux.net/~pesco/ which now contains the following: ghc-4.08.2-hc-unreg.tar.bz2 unregisterised HC files for GHC 4.08.2 ghc-4.08.2-powerpc-unknown-linux.tar.bz2 an unregisterised binary-dist of GHC 4 without profiling libraries or documentation ghc-5.04.3-powerpc-unknown-linux.tar.bz2 an unregisterised binary-dist of GHC 5 with profiling libraries, documentation, and a broken GHCi ghc-5.04.3-linuxppc.diff a patch with all the changes I made to the GHC 5 sources from which the above compiler was built experience.txt a diary of what I did on my way from HC files to a working GHC 5; this might be worth keeping (maybe linked from the GHC commentary or so) Since the machine hosting this is Shae's home internet gateway, I'm kindly asking you to publish the files on the GHC webspace. Thanks, Sven Moritz Hallberg

1 0

RE: Exception handler missimg in GHC.Handle.hs
by Simon Marlow 11 Apr '03

11 Apr '03

> If someone has aknowledged this problem, please reply, I'm > getting the feeling nobody want's to do anything about it... I've been away for a few days, and I'm now catching up. Sorry for the delay. > Brief description: if the remote side of a socket closes the > connection, > any write will cause a sigPIPE signal, if a > signal handler ignoring the signal is in place this results in an IO > exception in the write call (or flush). At this point > the local end of the socket still exists and needs to be closed by a > call to c_close, howerver, hClose and the finalizer > both try to flush the write side causeing a second exception, > resulting > in the handle never getting closed, and leaking... > > Here is a potential solution: (maybe better to use catchJust ioErrors) > > handleFinalizer :: MVar Handle__ -> IO () > handleFinalizer m = do > h_ <- takeMVar m > catch (flushWriteBufferOnly h_) (\e -> return()) -- catch > exception > if remote side closed > let fd = fromIntegral (haFD h_) > unlockFile fd > when (fd /= -1) > #ifdef mingw32_TARGET_OS > (closeFd (haIsStream h_) fd >> return ()) > #else > (c_close fd >> return ()) > #endif > return () Yes, that's a good bug. The buffer flushing operations are interruptible, so we should guard against asynchronous exceptions being delivered at those points. Cheers, Simon

1 0