- ghc-devs - Haskell.org

Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
by Luke Iannini 13 Aug '13

13 Aug '13

Hi Stephen/all, I got LLVM 3.0 installed and started building again but hit a very strange problem now wherein tons of layout-based code (as in http://en.wikibooks.org/wiki/Haskell/Indentation) is suddenly erroring out, e.g. compiler/coreSyn/CoreUnfold.lhs:481:2: parse error (possibly incorrect indentation or mismatched brackets) (some files also seem to be triggered by mixed tabs and spaces) I can fix the errors one by one by converting the code to use more concrete indentation (like do thing1 thing2 ) but it's all over the tree. Anyone have any idea what might cause this? Cheers Luke On Fri, Aug 9, 2013 at 6:14 AM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen(a)blacksapphire.com> wrote: > Luke, > > Try llvm version 3.0 - that's what I'm using, and it definitely worked > before. llvm-3.1 is broken for GHC+ARM. As for llvm >= 3.2, I'm not sure if > it's been fixed yet, but it wasn't working last time I tried a couple of > months ago. I think this was because llvm is getting fussier about its > input and GHC hasn't been "tightened up" yet. > > It's really easy to build llvm from source. > > > Steve > > > On 09/08/13 20:35, Luke Iannini wrote: > >> v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1f<https://gist.github.com/lukexi/7ca55b36269703236f1f> >> >> >> On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <lukexipd(a)gmail.com >> <mailto:lukexipd@gmail.com>> wrote: >> >> OK, that got me past that one. >> >> Now I'm stuck here during compilation of integer-simple: >> https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9<https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9> >> >> ("unsupported relocation on symbol"/"co-processor offset out of >> range") >> >> >> On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini <lukexipd(a)gmail.com >> <mailto:lukexipd@gmail.com>> wrote: >> >> OK, I'm underway on this. >> >> First roadbump was: >> >> >> "inplace/bin/ghc-stage1" -static -H32m -O -Iincludes >> -Iincludes/dist -Iincludes/dist-**derivedconstants/header >> -Iincludes/dist-ghcconstants/**header -Irts -Irts/dist/build >> -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts >> -irts/dist/build -irts/dist/build/autogen -Irts/dist/build >> -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o >> rts/dist/build/Apply.o >> >> >> >> >> You are using a new version of LLVM that hasn't been tested yet! >> We will try though... >> /usr/local/bin/llc: : error: unable to get target for >> 'arm-apple-darwin10', see --version and --triple. >> >> >> which I figured out were because the homebrew LLVM 3.4 only >> includes host platforms by default (x86/x86-64) >> Reinstalling it with all-targets enables them all: >> brew install llvm --with-clang --all-targets --HEAD >> >> Trying again now. >> >> >> >> >> On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini <lukexipd(a)gmail.com >> <mailto:lukexipd@gmail.com>> wrote: >> >> Update: I've got GHC HEAD building on 10.9 again, tonight >> I'll dive into the iOS patch! >> Cheers >> Luke >> >> >> On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald >> <carter.schonwald(a)gmail.com >> <mailto:carter.schonwald@**gmail.com<carter.schonwald(a)gmail.com>>> >> wrote: >> >> if you're on 10.8, just DL the 4.6 CLI tools to get >> things working again. >> >> If you're on 10.9, you'll need to use recent GHC head + >> CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI >> tools may have all the needed clang patches, but thats >> still needing its own validation, orthogonal to the IOS >> related issues ) >> >> >> On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini >> <lukexipd(a)gmail.com <mailto:lukexipd@gmail.com>> wrote: >> >> Hi Stephen, >> >> I installed 10.9 for another project and thus am in >> the middle of fixing up my system to be able to >> build GHC again, but I think I'm close — as soon as >> I have it going I'll try this. >> >> In the meantime someone still on 10.8 should >> definitely try the patch! >> >> Hope you're great! >> Luke >> >> >> On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath >> [to GHC-iPhone] >> <likeliest.complexions.%2A%2Astephen(a)blacksapphire.com<likeliest.complexions.stephen(a)blacksapphire.com> >> <mailto:likeliest.complexions.** >> stephen(a)blacksapphire.com<likeliest.complexions.stephen(a)blacksapphire.com> >> >> >> >> wrote: >> >> Hi all, >> >> A couple of months ago I got some patches >> applied to GHC mainline for the ability to cross >> compile to iOS. I've been doing other things and >> now I want to test those changes. The trouble >> is, I am having Apple trouble and I can't get >> Xcode to work. >> >> If anyone is interested in testing it for me, >> I'd appreciate it. >> >> The patch attached here needs to be applied to >> GHC head. Using this, I was able to get the >> cross compiler to build. The instructions are >> here: >> >> http://ghc.haskell.org/trac/__** >> ghc/wiki/Building/__**CrossCompiling/iOS<http://ghc.haskell.org/trac/__ghc/wiki/Building/__CrossCompiling/iOS> >> >> <http://ghc.haskell.org/trac/**ghc/wiki/Building/ >> **CrossCompiling/iOS<http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS> >> > >> >> >> Steve >> >> ______________________________**_________________ >> iPhone mailing list >> iPhone(a)haskell.org <mailto:iPhone@haskell.org> >> >> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >> >> >> >> ______________________________**_________________ >> iPhone mailing list >> iPhone(a)haskell.org <mailto:iPhone@haskell.org> >> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >> >> >> >> >> >> >>

2 8

Proposal: provide cas and barriers symbols even without -threaded
by Ryan Newton 12 Aug '13

12 Aug '13

The "atomic-primops" library depends on symbols such as store_load_barrier and "cas", which are defined in SMP.h. Thus the result is that if the program is linked WITHOUT "-threaded", the user gets a linker error about undefined symbols. The specific place it's used is in the 'foreign "C"' bits of this .cmm code: https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93… I'm trying to explore hacks that will enable me to pull in those functions during compile time, without duplicating a whole bunch of code from the RTS. But it's a fragile business. It seems to me that some of these routines have general utility. In future versions of GHC, could we consider linking in those routines irrespective of "-threaded"? -Ryan

4 30

request for reviews for my first patch -- ticket 7401
by Ömer Sinan Ağacan 12 Aug '13

12 Aug '13

Hi all, I just started GHC development made a commit for ticket 7401: http://ghc.haskell.org/trac/ghc/ticket/7401 My patch is here: https://github.com/osa1/ghc/commit/3ec257ff48372de30df59cd8854ce28954c9db95 `make test` succeeds. My test case for this patch is something like this: data D deriving Eq main :: IO () main = print ((undefined :: D) == (undefined :: D)) example: ➜ haskell ./ghc/inplace/bin/ghc-stage2 --interactive derive.hs GHCi, version 7.7.20130806: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( derive.hs, interpreted ) Ok, modules loaded: Main. ghci> main True it :: () This behavior(returning True) is consistent with standalone deriving version: ➜ haskell cat derive_standalone.hs {-# LANGUAGE StandaloneDeriving #-} data D deriving instance Eq D main :: IO () main = print ((undefined :: D) == (undefined :: D)) ➜ haskell ./ghc/inplace/bin/ghc-stage2 --interactive derive_standalone.hs GHCi, version 7.7.20130806: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( derive_standalone.hs, interpreted ) Ok, modules loaded: Main. ghci> main True it :: () ghci> Leaving GHCi. However, if you want (==) implementation in this case to be `error "Void (==)`, I think I can also do that by first fixing the code generated by StandaloneDeriving extension and then fixing my current patch. Any comments and reviews would be appreciated! --- Ömer Sinan Ağacan http://osa1.net

4 8

Another request for reviews -- ticket 3452
by Ömer Sinan Ağacan 12 Aug '13

12 Aug '13

Hi all, I'm a starter who just made his second patch for another simple task from trac. I updated current status of ticket to "patch" but I guess I also need to post here to get some reviews on this. Ticket: http://ghc.haskell.org/trac/ghc/ticket/3452 Patch is linked there with an example output and some comments. Thanks, --- Ömer Sinan Ağacan http://osa1.net

1 0

Cannot compile phase 2 after recent Roles patch
by Dr. ERDI Gergo 12 Aug '13

12 Aug '13

Hi, I cannot compile GHC starting from e8aa8ccb 'Implement "roles" into GHC'. The error message I get is: >>>>>>>>>>>>>>>>>>>>>>>>> *** Core Lint errors : in result of Desugar (after optimization) *** {-# LINE 290 "libraries/terminfo/System/Console/Terminfo/Base.hs #-}: Warning: [RHS of System.Console.Terminfo.Base.mkCallback :: System.Console.Terminfo.Base.CharOutput -> GHC.Types.IO (GHC.Ptr.FunPtr System.Console.Terminfo.Base.CharOutput)] Role incompatibility: expected P, got R in Sym Foreign.C.Types.NTCo:CInt[0] -> (GHC.Types.IO (Sym Foreign.C.Types.NTCo:CInt[0]))_R <<<<<<<<<<<<<<<<<<<<<<<< followed by a dump of Core (see attached). -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' chown -R us.us yourbase (#gnome)

2 2

SV: ./configure not using system MinGW
by Niklas Larsson 12 Aug '13

12 Aug '13

Hi! It's perfectly normal, to use that gcc. What it should do is to check out the ghc-tarballs repo and unpack a gcc from there. Now that I think of it, I had to manually get that repo last time. Maybe sync-all is broken? . Niklas ----- Ursprungligt meddelande ----- Från: "Kyle Van Berendonck" <kvanberendonck(a)gmail.com> Skickat: ‎2013-‎08-‎12 10:04 Till: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Ämne: ./configure not using system MinGW Hi, I tried to build GHC on windows recently and for some reason it tries to use a MinGW in repopath/inplace/mingw. I had to copy my entire mingw installation there to get it to configure. This isn't normal, right? Regards.

1 0

./configure not using system MinGW
by Kyle Van Berendonck 12 Aug '13

12 Aug '13

Hi, I tried to build GHC on windows recently and for some reason it tries to use a MinGW in repopath/inplace/mingw. I had to copy my entire mingw installation there to get it to configure. This isn't normal, right? Regards.

1 0

Machine-readable nightly output
by Edward Z. Yang 12 Aug '13

12 Aug '13

Hey Geoffrey, The nightly builds are running on your box, correct? How hard would it be to modify the nightly scripts so that they also output machine-readable information about the build? For example, we could then setup a fingerprint database, where given some revision of head, you could find out if it built, and what the hashes of all the repositories it built with were. Edward

2 2

Successful build of GHC HEAD on OS X 10.9 Mavericks
by Luke Iannini 12 Aug '13

12 Aug '13

Hi guys, Just wanted to report on the steps/hacks to a successful build of GHC HEAD on OS X 10.9 thanks to help from Carter Schonwald and Austin Seipp. 1) I installed LLVM 3.4 brew install llvm --with-clang --HEAD 2) I used this build.mk: HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO SPLIT_OBJS = NO INTEGER_LIBRARY = integer-simple 3) Austin let me know I needed to pass "-x assembler-with-cpp" to clang when in preprocessor mode, so I wrote a wrapper clang.hs, compiled it, put it in my path, and changed /usr/local/lib/ghc-7.6.2/settings to use it. (it also passes some flags Carter suggested, along with extra include flags, which were necessary as of a couple weeks ago but might have been fixed in the newer DPs) https://gist.github.com/lukexi/e11668ced04524564a8b 4) I used ./configure --with-gcc=clang (where clang is the wrapper script above) 5) "inplace/bin/mkdirhier" bootstrapping/. failed mysteriously, so I manually created bootstrapping/ in the ghc build dir. 6) DTrace failed with an "unsupported compiler" error during compilation, so I killed that section in configure.ac # if test -n "$DtraceCmd"; then # if test "x$TargetOS_CPP-$TargetVendor_CPP" = "xdarwin-apple" -o "x$TargetOS_CPP-$TargetVendor_CPP" = "xsolaris2-unknown"; then # HaveDtrace=YES # fi # fi 7) I got the error: libraries/integer-simple/GHC/Integer/Type.hs:836:50: Not in scope: '.' libraries/integer-simple/GHC/Integer/Type.hs:847:67: Not in scope: '.' I hacked through this by manually find-and-replacing WORD_SIZE_IN_BITS with 64 in Type.hs. make && make install then ran to completion and some simple test programs seem to compile and run fine. Cheers Luke

4 4

NOTICE: The Big Gitolite Switch
by Austin Seipp 09 Aug '13

09 Aug '13

Hello all, Following our proposal from about a week ago, Herbert and I plan to make the Gitolite migration happen Real Soon Now. If possible, we would actually like to have it happen tomorrow, although that's understandably a bit too short of a window of warning perhaps. However, commit activity has been low the past two weeks, so sometime in the next few days is probably the best window (Simon gets back August 15th, so we would like something in place by then.) We already have just about everything in place I believe. This is a final call for anyone who might need shell access or something of the sorts. I envision the plan will go like this: * We will turn off push access to the repositories, AND turn off shell access, by revoking SSH keys temporarily from everyone in the 'darcs' group (don't worry, there will be backups.) * I'll take everyone who has committed to any of the repositories in the last 1yr and add them to the new setup. That'll cover most of the current group, I think. There may be some people who were recently added but haven't committed yet. I'll try to remember everyone, but please yell if there is a problem. * We'll make the switch to gitolite by reinstating the SSH keys that are already there, and reopen the tree. We WILL NOT be deleting the existing user accounts. I don't want to possibly destroy something left there. Instead, if you would like, you can just email me and I'll re-add your key if necessary to get your stuff back. I expect this will be a very short and easy migration. Herbert has already given details of changing your existing trees via ./sync-all as well: http://www.mail-archive.com/ghc-devs@haskell.org/msg01781.html I will follow up with a reply to this email containing precise details on the switch, including the expected downtime window, and what time it will be happening. Please let me know if you have questions or concerns. -- Regards, Austin - PGP: 4096R/0x91384671

1 2