- cabal-devel - Haskell.org

System.Directory.findExecutable and ghc's ld in Windows
by Esa Ilari Vuokko 15 May '06

15 May '06

Hi! (please CC me as I am not subscribed) Happens on Cabal darcs head and Windows with ghc. In Distribution.Simple.GHC.build we try to invoke ld. In Windows this file is found by deduction from ghc.exe path. (foo\bin\ghc.exe -> foo\gcc-lib\ld.exe). When this absolute (rooted) path is passed on to rawSystem*, it gets search through PATH environment-variable in System.Directory.findExecutable (or the version in Compat.) System.Directory.findExecutable went through a rewrite for Windows between 6.4 series and 6.5 - it now uses Windows API function SearcPath which passes absolute paths straight throuhg, at least on my system (Windows XP). In the end, because 6.4.2 doesn't let absolute paths through, we need a fix. What is the right way here? Assume ghc 6.4.3 and get fix merged (see diff [1]); Add extra check for absolute path and file existence on findExecutable (and propagate this fix to base); Or inline the rawSystem* (as needed) in GHC.hs under correct preprocessor if's? Oh, yeah, we can also say that ghci libs just don't work under 6.4.x in Windows ;) Please advice. [1] http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/Dir… Best regards, --Esa

2 1

[shelarcy] Re: Cabal-Install doesn't work well on Windows.
by Isaac Jones 11 May '06

11 May '06

Would anyone care to try to get cabal-install going on windows? Or should we see about getting it going correctly in Unix first? peace, isaac

2 1

[patch] Workaround for ar and ld for Windows cmdline length restriction
by Esa Ilari Vuokko 10 May '06

10 May '06

Hi I have prepared a patch that works around Windows 32k command line length restriction when invoking ar and ld, this makes using ghc's split-objs possible in practice. Tue May 9 04:15:32 FLE Daylight Time 2006 Esa Ilari Vuokko <ei(a)vuokko.info> * Workaround for ar and ld for Windows cmdline length restriction There is no guarantee that algorithm works, ideally I should cut the lines at 32k, but instead I just call ar/ld for each one hundred files. Ld's case is a bit more complicated, with temp files. Algorithms aren't perfect, but I think they fit practically all packages out there (who has path to object file longer than 320+ characters, and hundred more?) Better solution would be to use ar's and ld's @file-functionality, but this isn't available in mingw's stable (or whatever) binutils yet, and of course builds for 6.4.x series will never have them, so it'd need ar/ld version checking which isn't totally trivial to add. Best regards, --Esa PS. Please CC me on replies as I am not subscribed. PSS. It seems to me that indentation in source has both tabs and spaces. That feels risky.

2 1

Re: Cabal-Install doesn't work well on Windows.
by shelarcy 10 May '06

10 May '06

Hello. On Thu, 04 May 2006 09:31:35 +0900, Isaac Jones <ijones(a)syntaxpolice.org> wrote: > I'm sorry I didn't reply earlier. We're scrapping that version of > cabal-install and replacing it with a better version that can download > packages from the internet. I'd certainly be happy to hear any > reports of how this works on windows. I don't know if it works at > all, and so any help would be great. Windows (mingw) version of GHC has no System.Posix.Signals functions and Types. System.Posix.Signals module exist, but no definition now. Because Windows' native posix support is very very poor, so signal support is also poor. Cause of these reason. I can't build cabal-install on Windows Enviorment. runhaskell Setup.lhs build notice these errors; ----- ../Network/Hackage/CabalInstall/Install.hs:107:39 Not in scope: `installHandler' ../Network/Hackage/CabalInstall/Install.hs:107:54 Not in scope: `keyboardSignal' ../Network/Hackage/CabalInstall/Install.hs:107:70 Not in scope: data constructor `Catch' ../Network/Hackage/CabalInstall/Install.hs:109:25 Not in scope: `installHandler' ../Network/Hackage/CabalInstall/Install.hs:109:40 Not in scope: `keyboardSignal' ---- Does anyone have plan to support cabakl-install on Windows? Or does anyone know that how to solove these problems? -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

1 0

darcs patch: Change calls to 'make' into '$(MAKE)'
by Duncan Coutts 03 May '06

03 May '06

Tue May 2 18:46:30 BST 2006 Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> * Change calls to 'make' into '$(MAKE)' This is the portable thing to do and fixes things on FreeBSD where make/=gmake

1 0