Re: ARM64 Task Force
Hi all, An update on this -- I've made a bit of progress thanks to Karel and Colin's start at ARM64 support https://ghc.haskell.org/trac/ghc/ticket/7942 With a few tweaks*, that let me build a GHC that builds ARM64 binaries and load them onto my iPad Air, which is great! But of course they don't work yet since LLVM doesn't have the ARM64/GHC calling convention in. Happily I was able to use LLVM HEAD to do this, which means we don't need to be bound to Xcode's release schedules. I'm now studying David's patches to LLVM to learn how to add the ARM64/GHC calling convention to LLVM. *including Ben Gamari's patches to get LLVM HEAD working https://github.com/bgamari/ghc/tree/llvm-3.5-new Best Luke On Mon, Jul 7, 2014 at 11:06 PM, Luke Iannini wrote: > Howdy all, > > Would anyone like to team up on getting ARM64 support into GHC? > > Cheers > Luke > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
Hi Karel, Thanks! A question: https://git.haskell.org/ghc.git/commitdiff/454b34cb3b67dec21f023339c4d53d734af7605d adds references to s16, s17, s18, s19, d10 and d11 but I don't see those where I though to expect them in https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs Am I down a wrong path? Luke On Thu, Aug 7, 2014 at 10:58 PM, Karel Gardas wrote: > On 08/ 8/14 01:58 AM, Luke Iannini wrote: > >> I'm now studying David's patches to LLVM to learn how to add the >> ARM64/GHC calling convention to LLVM. >> > > Here is also original ARM/GHC calling convention submission. It's always > good to have more examples as reference... > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044173.html > > Good luck with the ARM64/GHC porting work! > > Karel > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
I think I've solved this particular mystery -- the registers were never defined there because that integer-representation of them is only used by the NCG. In LLVM land they were only ever stringified by the REG() macro. Except now globalRegMaybe is being used in CmmSink.hs (as Simon and Ben were discussing), and globalRegMaybe needs an integer value for each register to put into its Maybe RealReg return value. Since CmmSink.hs only checks 'isJust', it doesn't actually matter what the integer value is. So I've just gone ahead and defined them sequentially for now which seems to get me past this. Thanks! Luke On Sat, Aug 9, 2014 at 4:22 AM, Karel Gardas wrote: > On 08/ 9/14 05:27 AM, Luke Iannini wrote: > >> Hi Karel, >> Thanks! >> >> A question: >> https://git.haskell.org/ghc.git/commitdiff/454b34cb3b67dec21f023339c4d53d >> 734af7605d >> adds references to s16, s17, s18, s19, d10 and d11 but I don't see those >> > > Yes, that adds FPU support for ARM. > > > where I though to expect them in >> https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs >> > > Hmm, whole ARM reg set is missing in this file. IIRC Simon Marlow were > discussing this with Ben Gamari recently. I've not investigated if this is > needed or not since I don't know if this is used only in NCG or in > registerised build in general. If the former, ARM will not be there as > there is no ARM NCG yet, if the later, then ARM should be there as > ARM/LLVM/registerised build is a reality. > > Cheers, > Karel > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
I've pushed my WIP patches here: https://github.com/lukexi/llvm/commit/dfe74bb48eb05ce7847fa262f6e563d20d0b1fc5 https://github.com/lukexi/ghc/commit/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e (they also require the latest libffi to be dropped in ftp://sourceware.org/pub/libffi/libffi-3.0.13.tar.gz due to https://ghc.haskell.org/trac/ghc/ticket/8664) These can produce an ARM64 GHC but the produced binaries aren't fully functional yet. They make it through hs_init() but crash rather opaquely when I try to call a simple fib function through the FFI. It looks like it's jumping somewhere strange; lldb tells me it's to 0x100e05110: .long 0x; unknown opcode 0x100e05114: .long 0x; unknown opcode 0x100e05118: .long 0x; unknown opcode 0x100e0511c: .long 0x; unknown opcode 0x100e05120: .long 0x; unknown opcode 0x100e05124: .long 0x; unknown opcode 0x100e05128: .long 0x; unknown opcode 0x100e0512c: .long 0x; unknown opcode If I put a breakpoint on StgRun and step by instruction, I seem to make it to about: https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e/rts/StgCRun.c#L770 (give or take a line) before something goes mysteriously wrong and I'm no longer able to interact with the debugger. So I guess I'll try taking out float register support and see if that gets me anywhere. If anyone has some ideas on how to debug this I'd love to hear them! I've mostly assembled the patches by adapting the existing ARM support so it's quite possibly I'm doing something boneheaded. Cheers Luke On Sun, Aug 10, 2014 at 6:44 PM, Luke Iannini wrote: > I think I've solved this particular mystery -- the registers were never > defined there because that integer-representation of them is only used by > the NCG. In LLVM land they were only ever stringified by the REG() macro. > > Except now globalRegMaybe is being used in CmmSink.hs (as Simon and Ben > were discussing), and globalRegMaybe needs an integer value for each > register to put into its Maybe RealReg return value. Since CmmSink.hs only > checks 'isJust', it doesn't actually matter what the integer value is. > > So I've just gone ahead and defined them sequentially for now which seems > to get me past this. > > Thanks! > Luke > > > On Sat, Aug 9, 2014 at 4:22 AM, Karel Gardas > wrote: > >> On 08/ 9/14 05:27 AM, Luke Iannini wrote: >> >>> Hi Karel, >>> Thanks! >>> >>> A question: >>> https://git.haskell.org/ghc.git/commitdiff/ >>> 454b34cb3b67dec21f023339c4d53d734af7605d >>> adds references to s16, s17, s18, s19, d10 and d11 but I don't see those >>> >> >> Yes, that adds FPU support for ARM. >> >> >> where I though to expect them in >>> https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs >>> >> >> Hmm, whole ARM reg set is missing in this file. IIRC Simon Marlow were >> discussing this with Ben Gamari recently. I've not investigated if this is >> needed or not since I don't know if this is used only in NCG or in >> registerised build in general. If the former, ARM will not be there as >> there is no ARM NCG yet, if the later, then ARM should be there as >> ARM/LLVM/registerised build is a reality. >> >> Cheers, >> Karel >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
Hi all, Yahoo, happy news -- I think I've got it. Studying enough of the non-handwritten ASM that I was stepping through led me to make this change: https://github.com/lukexi/ghc/commit/1140e11db07817fcfc12446c74cd5a2bcdf92781 (I think disabling the floating point registers was just a red herring; I'll confirm that next) And I can now call this fib code happily via the FFI: fibs :: [Int] fibs = 1:1:zipWith (+) fibs (tail fibs) foreign export ccall fib :: Int -> Int fib :: Int -> Int fib = (fibs !!) For posterity, more detail on the crashing case earlier (this is fixed now with proper storage and updating of the frame pointer): Calling fib(1) or fib(2) worked, but calling fib(3) triggered the crash. This was the backtrace, where you can see the errant 0x000100f05110 frame values. (lldb) bt * thread #1: tid = 0xac6ed, 0x000100f05110, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100f05110) frame #0: 0x000100f05110 frame #1: 0x000100f05110 * frame #2: 0x0001000ffc9c HelloHaskell`-[SPJViewController viewDidLoad](self=0x000144e0cf10, _cmd=0x000186ae429a) + 76 at SPJViewController.m:22 frame #3: 0x0001862f8b70 UIKit`-[UIViewController loadViewIfRequired] + 692 frame #4: 0x0001862f8880 UIKit`-[UIViewController view] + 32 frame #5: 0x0001862feeb0 UIKit`-[UIWindow addRootViewControllerViewIfPossible] + 72 frame #6: 0x0001862fc6d4 UIKit`-[UIWindow _setHidden:forced:] + 296 frame #7: 0x00018636d2bc UIKit`-[UIWindow makeKeyAndVisible] + 56 frame #8: 0x00018657ff74 UIKit`-[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 2804 frame #9: 0x0001865824ec UIKit`-[UIApplication _runWithMainScene:transitionContext:completion:] + 1480 frame #10: 0x000186580b84 UIKit`-[UIApplication workspaceDidEndTransaction:] + 184 frame #11: 0x000189d846ac FrontBoardServices`__31-[FBSSerialQueue performAsync:]_block_invoke + 28 frame #12: 0x000181c7a360 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20 frame #13: 0x000181c79468 CoreFoundation`__CFRunLoopDoBlocks + 312 frame #14: 0x000181c77a8c CoreFoundation`__CFRunLoopRun + 1756 frame #15: 0x000181ba5664 CoreFoundation`CFRunLoopRunSpecific + 396 frame #16: 0x000186363140 UIKit`-[UIApplication _run] + 552 frame #17: 0x00018635e164 UIKit`UIApplicationMain + 1488 frame #18: 0x000100100268 HelloHaskell`main(argc=1, argv=0x00016fd07a58) + 204 at main.m:24 frame #19: 0x0001921eea08 libdyld.dylib`start + 4 On Tue, Aug 12, 2014 at 11:24 AM, Karel Gardas wrote: > On 08/12/14 11:03 AM, Luke Iannini wrote: > >> It looks like it's jumping somewhere strange; lldb tells me it's to >> 0x100e05110: .long 0x ; unknown opcode >> 0x100e05114: .long 0x ; unknown opcode >> 0x100e05118: .long 0x ; unknown opcode >> 0x100e0511c: .long 0x ; unknown opcode >> 0x100e05120: .long 0x ; unknown opcode >> 0x100e05124: .long 0x ; unknown opcode >> 0x100e05128: .long 0x ; unknown opcode >> 0x100e0512c: .long 0x ; unknown opcode >> >> If I put a breakpoint on StgRun and step by instruction, I seem to make >> it to about: >> https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f >> 0e302e321e/rts/StgCRun.c#L770 >> (give or take a line) >> > > strange that it's in the middle of the stp isns block. Anyway, this looks > like a cpu exception doesn't it? You will need to find out the reg which > holds the "exception reason" value and then look on it in your debugger to > find out what's going wrong there. > > Karel > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
Indeed, the float register stuff was a red herring -- restoring it caused no problems and all my tests are working great. So yahoo!! We've got ARM64 support. I'll tidy up the patches and create a ticket for review and merge. Luke On Tue, Aug 12, 2014 at 4:47 PM, Luke Iannini wrote: > Hi all, > Yahoo, happy news -- I think I've got it. Studying enough of the > non-handwritten ASM that I was stepping through led me to make this change: > > https://github.com/lukexi/ghc/commit/1140e11db07817fcfc12446c74cd5a2bcdf92781 > (I think disabling the floating point registers was just a red herring; > I'll confirm that next) > > And I can now call this fib code happily via the FFI: > fibs :: [Int] > fibs = 1:1:zipWith (+) fibs (tail fibs) > > foreign export ccall fib :: Int -> Int > fib :: Int -> Int > fib = (fibs !!) > > For posterity, more detail on the crashing case earlier (this is fixed now > with proper storage and updating of the frame pointer): > Calling fib(1) or fib(2) worked, but calling fib(3) triggered the crash. > This was the backtrace, where you can see the errant 0x000100f05110 > frame values. > (lldb) bt > * thread #1: tid = 0xac6ed, 0x000100f05110, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, > address=0x100f05110) > frame #0: 0x000100f05110 > frame #1: 0x000100f05110 > * frame #2: 0x0001000ffc9c HelloHaskell`-[SPJViewController > viewDidLoad](self=0x000144e0cf10, _cmd=0x000186ae429a) + 76 at > SPJViewController.m:22 > frame #3: 0x0001862f8b70 UIKit`-[UIViewController > loadViewIfRequired] + 692 > frame #4: 0x0001862f8880 UIKit`-[UIViewController view] + 32 > frame #5: 0x0001862feeb0 UIKit`-[UIWindow > addRootViewControllerViewIfPossible] + 72 > frame #6: 0x0001862fc6d4 UIKit`-[UIWindow _setHidden:forced:] + 296 > frame #7: 0x00018636d2bc UIKit`-[UIWindow makeKeyAndVisible] + 56 > frame #8: 0x00018657ff74 UIKit`-[UIApplication > _callInitializationDelegatesForMainScene:transitionContext:] + 2804 > frame #9: 0x0001865824ec UIKit`-[UIApplication > _runWithMainScene:transitionContext:completion:] + 1480 > frame #10: 0x000186580b84 UIKit`-[UIApplication > workspaceDidEndTransaction:] + 184 > frame #11: 0x000189d846ac FrontBoardServices`__31-[FBSSerialQueue > performAsync:]_block_invoke + 28 > frame #12: 0x000181c7a360 > CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20 > frame #13: 0x000181c79468 CoreFoundation`__CFRunLoopDoBlocks + 312 > frame #14: 0x000181c77a8c CoreFoundation`__CFRunLoopRun + 1756 > frame #15: 0x000181ba5664 CoreFoundation`CFRunLoopRunSpecific + 396 > frame #16: 0x000186363140 UIKit`-[UIApplication _run] + 552 > frame #17: 0x00018635e164 UIKit`UIApplicationMain + 1488 > frame #18: 0x000100100268 HelloHaskell`main(argc=1, > argv=0x00016fd07a58) + 204 at main.m:24 > frame #19: 0x0001921eea08 libdyld.dylib`start + 4 > > > > On Tue, Aug 12, 2014 at 11:24 AM, Karel Gardas > wrote: > >> On 08/12/14 11:03 AM, Luke Iannini wrote: >> >>> It looks like it's jumping somewhere strange; lldb tells me it's to >>> 0x100e05110: .long 0x ; unknown opcode >>> 0x100e05114: .long 0x ; unknown opcode >>> 0x100e05118: .long 0x ; unknown opcode >>> 0x100e0511c: .long 0x ; unknown opcode >>> 0x100e05120: .long 0x ; unknown opcode >>> 0x100e05124: .long 0x ; unknown opcode >>> 0x100e05128: .long 0x ; unknown opcode >>> 0x100e0512c: .long 0x ; unknown opcode >>> >>> If I put a breakpoint on StgRun and step by instruction, I seem to make >>> it to about: >>> https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f >>> 0e302e321e/rts/StgCRun.c#L770 >>> (give or take a line) >>> >> >> strange that it's in the middle of the stp isns block. Anyway, this looks >> like a cpu exception doesn't it? You will need to find out the reg which >> holds the "exception reason" value and then look on it in your debugger to >> find out what's going wrong there. >> >> Karel >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status of GHC targetting ARM?
Hi Iavor! I work with/on GHC for iOS daily and have been using it on a large near-production project for ~2 years without trouble. We released binaries for iOS compilers as part of 7.8: http://www.haskell.org/ghc/download_ghc_7_8_3#ios along with these toolchain scripts https://github.com/ghc-ios/ghc-ios-scripts and Cabal works well with it too. I've recently completed a patchset for LLVM and GHC to add ARM64 support that I'll be submitting soon. As far as building GHC for iOS, all of the patches are in mainline except for an out-of-date libffi, and some tweaks to the bindist system when generating redistributable binaries. The only major missing piece is Template Haskell support. Best Luke On Wed, Aug 20, 2014 at 1:32 PM, Iavor Diatchki wrote: > Hello, > > Does anyone have information about the status of GHC cross-compiling to > ARM architectures? More specifically, I am interested in finding out what > works and what still needs to be done before we can get GHC to generate > binaries that can run on the various mobile platforms (Android, iOS). > > -Iavor > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.10 STABLE freeze date
Hello, I've submitted a patch to finish the already-merged (but incomplete) ARM64 support that adds support for modern iOS devices https://ghc.haskell.org/trac/ghc/ticket/7942 Best Luke (I've also submitted a patch to LLVM to add an ARM64 GHC calling convention that is in review) On Fri, Nov 7, 2014 at 1:35 PM Austin Seipp wrote: > Hi all, > > After some deliberation, we've decided that the STABLE freeze for 7.10 > will happen in approximately two weeks, on November 21st. We're hoping > to stick to this date closely, but do read below. > > This is perhaps a short time to freeze, but right now, we've only got > a couple things we're planning on focusing on for the next few weeks. > And these are really the major things we're waiting for. See below: > > - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 > > These are just: > > - D155, LLVM 3.5 compatibility, > - D396 and D169, DWARF/source code note work. These are mostly in me > and Simon's court to do another review round, but I think will be OK > to get them in on time. > - D168, Partial type signatures. The ball is in Simon's court on this > one, but he's had several good rounds of discussion with Thomas etc > from what I understand. > > Based on our discussions earlier this week, I think these all will > make it just in time for the freeze. > > Nota bene: if there is *any* delay, it will be for these, as we picked > them as the highest priority in our own views. It is unlikely we will > delay any so people can sneak in a few other things. So, if you want > something of yours in, you better get me, Simon & Simon, Herbert, > etc's attention pronto! That way we'll have time to get it in first. > > To make things easier, we'll also be pushing the lhs->hs conversion > pretty soon so cherry picking/merges are easier, and do some other > cleanups. > > And outside of that, we've still been having a healthy flow of bug > fixes falling into the tree, which is great. So if you're just > bugfixing, please keep doing so - we'll be pulling bugfixes into the > tree continuously. > > We will also be pulling in submodule/library updates continuously, > like we did for the 7.8 branch. > > Let me know if you have questions, objections, or really really really > want something - but I won't be as nice as last time I'm afraid. ;) > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: optllvm broken on master?
Whoops, that's my fault; it shouldn't have slipped into the patch -- this is required for LLVM 3.6 (which I was using to work on my ARM64 patch), but clearly isn't backwards compatible. I wonder what's best to do for this? Would it be correct to switch on LLVM versions or should this be considered a bug in LLVM? (it was the only change needed for 3.6) I will submit a ticket to revert that line in the meantime. Thanks! Luke On Thu, Nov 20, 2014 at 2:26 AM, Dr. ERDI Gergo wrote: > Hi, > > Tests fail on master when run the optllvm way, e.g.: > > /usr/bin/opt: /tmp/ghc16190_0/ghc16190_2.ll:611:25: error: expected > 'global' or 'constant' > @newCAF$alias = private alias i8* @newCAF > > I think it's the change in d87fa34: > > index 7307725..cdc407c 100644 > --- a/compiler/llvmGen/Llvm/PpLlvm.hs > +++ b/compiler/llvmGen/Llvm/PpLlvm.hs > @@ -80,7 +80,7 @@ ppLlvmGlobal (LMGlobal var@(LMGlobalVar _ _ link x a c) > dat) = > const_link = case c of >Global -> ppr link <+> text "global" >Constant -> ppr link <+> text "constant" > - Alias-> text "alias" <+> ppr link > + Alias-> ppr link <+> text "alias" > > in ppAssignment var $ const_link <+> rhs <> sect <> align > $+$ newLine > > > > -- > > .--= ULLA! =-. >\ http://gergo.erdi.hu \ > `---= ge...@erdi.hu =---' > If it ain't broke, I can fix it. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC ARM64 calling convention
Hi Erik! Really glad you found it. I did actually submit it to the LLVM team a couple months ago; the relevant email from Tim Northover is here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141103/243180.html He had a few small questions/requests and I've just been too pulled under by other projects to address them. If you want to give it the last nudge into glory I'd be thrilled : ) Cheers Luke On Sun, Dec 28, 2014 at 2:33 AM, Erik de Castro Lopo wrote: > Hi Luke, > > I found your llvm git tree which contains a patch [0] implementing the > GHC calling convention for GHC. I also notice that: > > a) It has not been submitted upstream. > b) It can be cherry picked and applied on top of current llvm HEAD. > c) It can be applied to the llvm 3.5 tree > > and most importantly of all > > d) It actually works. > > With this patch applied to the llvm 3.5 tree, I was able to build an > x86_64-linux to aarch64-linux cross-compiler which was able to build > a simple "hello world" program that actually ran correctly. > > Are you in the process of trying to get this patch into LLVM? Do you need > any help? > > Cheers, > Erik > > [0] > https://github.com/lukexi/llvm/commit/2d351c3d095e2fe42bc287947404d884841a1d01 > -- > -- > Erik de Castro Lopo > http://www.mega-nerd.com/ > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC ARM64 calling convention
(oh, and on the topic of Useful Work I've done but haven't had time to box up and ship, I backported the relevant ARM64 patches to GHC 7.8 here, in case it's useful to anyone: https://github.com/lukexi/ghc-7.8-arm64 ) On Sun, Dec 28, 2014 at 4:25 AM, Luke Iannini wrote: > Hi Erik! > > Really glad you found it. > > I did actually submit it to the LLVM team a couple months ago; the > relevant email from Tim Northover is here: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141103/243180.html > > He had a few small questions/requests and I've just been too pulled under > by other projects to address them. If you want to give it the last nudge > into glory I'd be thrilled : ) > > Cheers > Luke > > On Sun, Dec 28, 2014 at 2:33 AM, Erik de Castro Lopo > wrote: > >> Hi Luke, >> >> I found your llvm git tree which contains a patch [0] implementing the >> GHC calling convention for GHC. I also notice that: >> >> a) It has not been submitted upstream. >> b) It can be cherry picked and applied on top of current llvm HEAD. >> c) It can be applied to the llvm 3.5 tree >> >> and most importantly of all >> >> d) It actually works. >> >> With this patch applied to the llvm 3.5 tree, I was able to build an >> x86_64-linux to aarch64-linux cross-compiler which was able to build >> a simple "hello world" program that actually ran correctly. >> >> Are you in the process of trying to get this patch into LLVM? Do you need >> any help? >> >> Cheers, >> Erik >> >> [0] >> https://github.com/lukexi/llvm/commit/2d351c3d095e2fe42bc287947404d884841a1d01 >> -- >> -- >> Erik de Castro Lopo >> http://www.mega-nerd.com/ >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC crashing in checkProddableBlock during linking
Hi all, I'm encountering a crash in GHC 7.10.1 and 7.8.4 on Windows when I attempt to use Template Haskell in anything that relies on a package that contains C++; in my case, bindings to the Bullet physics engine. This is a pretty big blocker for me as I haven't found any good workarounds, so it would be awesome to get a fix in (I guess I just missed 7.10.2) I've made some progress here and a minimal reproduction if anyone can help: https://ghc.haskell.org/trac/ghc/ticket/10672 Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HEADS UP: Need 7.10.3?
My two showstoppers are https://ghc.haskell.org/trac/ghc/ticket/10568 and https://ghc.haskell.org/trac/ghc/ticket/10672, both of which seem to be already on track for 7.10.3, great! On Mon, Sep 14, 2015 at 7:15 AM, Tuncer Ayaz wrote: > On Mon, Sep 14, 2015 at 3:53 PM, Austin Seipp wrote: > > Hi *, > > > > (This is an email primarily aimed at users reading this list and > > developers who have any interest). > > > > As some of you may know, there's currently a 7.10.3 milestone and > > status page on our wiki: > > > > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.3 > > > > The basic summary is best captured on the above page: > > > > "We have not yet decided when, or even whether, to release GHC > > 7.10.3. We will do so if (but only if!) we have documented cases of > > "show-stoppers" in 7.10.2. Namely, cases from users where > > > > - You are unable to use 7.10.2 because of some bug > > - There is no reasonable workaround, so you are truly stuck > > - We know how to fix it > > - The fix is not too disruptive; i.e. does not risk introducing a > > raft of new bugs" > > > > That is, we're currently not fully sold on the need for a release. > > However, the milestone and issue page serve as a useful guide, and > > also make it easier to keep track of smaller, point-release worthy > > issues. > > > > So in the wake of the 8.0 roadmap I just sent: If you *need* 7.10.3 > > because the 7.10.x series has a major regression or problem you > > can't work around, let us know! > > > > - Find or file a bug in Trac > > - Make sure it's highest priority > > - Assign it to the 7.10.3 milestone > > - Follow up on this email if possible, or edit it on the status page > > text above - it would be nice to get some public feedback in one place > > about what everyone needs. > > > > Currently we have two bugs on the listed page in the 'show stopper > > category', possibly the same bug, which is a deal-breaker for HERMIT > > I believe. Knowing of anything else would be very useful. > > Would tracking down and fixing some of the reported time and space > regressions qualify as 7.10.3 material? > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: HEADS UP: Need 7.10.3?
Oh, and I guess it was implied, but I'm hugely in favor of a release : ) #10568 breaks linking with GLFW on Mac, and #10672 breaks linking with C++ libraries on Windows (Bullet Physics, in this case). We're working on and evangelizing Haskell for game and VR dev heavily right now and those are both directly in the critical path. Cheers Luke On Mon, Sep 14, 2015 at 3:21 PM, Luke Iannini wrote: > My two showstoppers are https://ghc.haskell.org/trac/ghc/ticket/10568 and > https://ghc.haskell.org/trac/ghc/ticket/10672, both of which seem to be > already on track for 7.10.3, great! > > On Mon, Sep 14, 2015 at 7:15 AM, Tuncer Ayaz > wrote: > >> On Mon, Sep 14, 2015 at 3:53 PM, Austin Seipp wrote: >> > Hi *, >> > >> > (This is an email primarily aimed at users reading this list and >> > developers who have any interest). >> > >> > As some of you may know, there's currently a 7.10.3 milestone and >> > status page on our wiki: >> > >> > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.3 >> > >> > The basic summary is best captured on the above page: >> > >> > "We have not yet decided when, or even whether, to release GHC >> > 7.10.3. We will do so if (but only if!) we have documented cases of >> > "show-stoppers" in 7.10.2. Namely, cases from users where >> > >> > - You are unable to use 7.10.2 because of some bug >> > - There is no reasonable workaround, so you are truly stuck >> > - We know how to fix it >> > - The fix is not too disruptive; i.e. does not risk introducing a >> > raft of new bugs" >> > >> > That is, we're currently not fully sold on the need for a release. >> > However, the milestone and issue page serve as a useful guide, and >> > also make it easier to keep track of smaller, point-release worthy >> > issues. >> > >> > So in the wake of the 8.0 roadmap I just sent: If you *need* 7.10.3 >> > because the 7.10.x series has a major regression or problem you >> > can't work around, let us know! >> > >> > - Find or file a bug in Trac >> > - Make sure it's highest priority >> > - Assign it to the 7.10.3 milestone >> > - Follow up on this email if possible, or edit it on the status page >> > text above - it would be nice to get some public feedback in one place >> > about what everyone needs. >> > >> > Currently we have two bugs on the listed page in the 'show stopper >> > category', possibly the same bug, which is a deal-breaker for HERMIT >> > I believe. Knowing of anything else would be very useful. >> >> Would tracking down and fixing some of the reported time and space >> regressions qualify as 7.10.3 material? >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: status of template haskell + cross compiling plans for 7.8?
Yo Carter, I worked with Stephen Blackheath earlier this year to help get his awesome iOS patches for Cabal and GHC into mainline and am also super keen to see TH support for cross compiling (which I think he is as well). So thanks for raising the issue, and just want to say that I'd be pumped to assemble and be a part of a team to work on this. Cheers Luke On Thu, Jun 13, 2013 at 11:59 PM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > > Which raises the question then: what would be needed to make this happen > by 7.10, if not sooner? > > naively, I'd imagine one part of the challenge is that Template haskell > induces needing a ghc that can build libraries for *BOTH* host and target, > because we have arbitrary execution at Template Haskell time, right? > > So does that mean fixing up GHC's architecture so that it can be built > with support for more than 1 target? (or at least running libs on *host* in > GHCI but otherwise compiling them for target? ) > > What would be needed in the restricted case of "We just want TH for our > cross compiler" rather than "general multi target goodness"? > > Because If I squint, it sort of sounds like the cross compiler would need > to be Stage 2, and that the UNsound but simplest approach would then be to > take the various "libways", and produce both host and target variants as > appropriate (or that "build HOST Way" has to explicitly flagged). I"m not > sure what implications this or another approach would have on all the > various build tooling needed etc etc. > > This is me just thinking out loud / trying to understand *why* and whats > needed, and how complex the work would be to do it well, or at least > decently in a way that *improves* (or doesn't complicate much more) the > associated parts that would need to be fixed up. > > > Basically: whats needed to make cross compiler GHC first class haskell > wrt TH support? (I imagine that its not worth working on till the new TH > work lands / stabilizes, but id like to understand what work has to be done > to lead up to it). > > (if I can figure out ways I can directly or indirectly support such work > happening, subject to having the time and/or resources over the next year, > i'd like to try and do so) > > -Carter > > > > > On Thu, Jun 13, 2013 at 8:28 PM, Manuel M T Chakravarty < > c...@cse.unsw.edu.au> wrote: > >> Carter, >> >> As you can imagine, I would be extremely happy about cross-compilation >> support for TH. However, I don't know of anybody working on it at the >> moment, unfortunately. >> >> Manuel >> >> Carter Schonwald : >> > Hey All, >> > Whats the story planned for template haskell + cross compiler support >> come ghc 7.8? >> > I understand theres a lot of Template Haskell design underway, some of >> which will help support tools like Manuel's Inline-Objective-C work. Does >> this mean that factored out within this reorganization is a better story >> for cross compilation? >> > >> > Especially since one kill "app" for the Inline-Objective-C template >> haskell work would be writing IOS applications. Though I guess that also >> touches on the need to sort out supporting "FAT" ARM binaries too, right? >> > >> > This intersects with a few different large subsets of tickets, so i'm >> not sure if any single ticket is the right fora for this question. >> > >> > thanks! >> > -Carter >> > ___ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Successful build of GHC HEAD on OS X 10.9 Mavericks
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Successful build of GHC HEAD on OS X 10.9 Mavericks
Yes, I'm at 3e598fe0b, couldn't tell you why it worked for me though : ). On Fri, Aug 9, 2013 at 3:33 AM, Dr. ERDI Gergo wrote: > On Fri, 9 Aug 2013, Luke Iannini wrote: > > 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. >> > > HEAD as of 3e598fe0b? I wasn't able to build that one because the Core > lint pass fails with the new Role checker. > > -- > > .--= ULLA! =-. >\ http://gergo.erdi.hu \ > `---= ge...@erdi.hu =---' > Don't anthropomorphize computers. They hate that. > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
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.step...@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 > <mailto:lukex...@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 > <mailto:lukex...@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 > <mailto:lukex...@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
>> >
>> <mailto:carter.schonwald@**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
>> mailto:lukex...@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.
>>
>>
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
The first error on a fresh checkout is
"/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O
-package-db libraries/bootstrapping.conf -hide-all-packages -i
-iutils/hsc2hs/. -iutils/hsc2hs/dist/build
-iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build
-Iutils/hsc2hs/dist/build/autogen -optP-include
-optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1
-package containers-0.5.0.0 -package directory-1.2.0.1 -package
filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP
-XForeignFunctionInterface -no-user-package-db -rtsopts -odir
utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o
utils/hsc2hs/dist/build/C.o
utils/hsc2hs/C.hs:155:3:
parse error (possibly incorrect indentation or mismatched brackets)
There seem to be two classes of error: one is the layout issue above, but
other files can be fixed by simply running 'expand' on them.
On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini wrote:
> 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.step...@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 >> <mailto:lukex...@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 >> <mailto:lukex...@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 >> <mailto:lukex...@gmail.com>> wrote:
>>>
>>
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
Further investigation:
I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the
problem still occurred.
The problem only occurs with LLVM 3.0.
It is not related to cross-compilation or Stephen's patches: I tested this
on multiple fresh clones with --with-gcc=clang.
LLVM 3.2, 3.3 and 3.4 do not exhibit the issue.
If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries
here Clang Binaries for MacOS
X/x86-64<http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz>
and
just drop them in your path.
(Stephen, I'm now trying your patch with LLVM 3.2)
Cheers
Luke
On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini wrote:
> The first error on a fresh checkout is
>
> "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O
> -package-db libraries/bootstrapping.conf -hide-all-packages -i
> -iutils/hsc2hs/. -iutils/hsc2hs/dist/build
> -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build
> -Iutils/hsc2hs/dist/build/autogen -optP-include
> -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1
> -package containers-0.5.0.0 -package directory-1.2.0.1 -package
> filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP
> -XForeignFunctionInterface -no-user-package-db -rtsopts -odir
> utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
> utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o
> utils/hsc2hs/dist/build/C.o
>
>
> utils/hsc2hs/C.hs:155:3:
>
> parse error (possibly incorrect indentation or mismatched brackets)
>
>
> There seem to be two classes of error: one is the layout issue above, but
> other files can be fixed by simply running 'expand' on them.
>
>
> On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini wrote:
>
>> 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.step...@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 >>> <mailto:lukex...@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 >>> <mailto:lukex...@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
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 do
not.
On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini wrote:
> Further investigation:
>
> I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the
> problem still occurred.
>
> The problem only occurs with LLVM 3.0.
>
> It is not related to cross-compilation or Stephen's patches: I tested this
> on multiple fresh clones with --with-gcc=clang.
>
> LLVM 3.2, 3.3 and 3.4 do not exhibit the issue.
>
> If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries
> here Clang Binaries for MacOS
> X/x86-64<http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz>
> and
> just drop them in your path.
>
> (Stephen, I'm now trying your patch with LLVM 3.2)
>
> Cheers
> Luke
>
>
> On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini wrote:
>
>> The first error on a fresh checkout is
>>
>> "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O
>> -package-db libraries/bootstrapping.conf -hide-all-packages -i
>> -iutils/hsc2hs/. -iutils/hsc2hs/dist/build
>> -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build
>> -Iutils/hsc2hs/dist/build/autogen -optP-include
>> -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1
>> -package containers-0.5.0.0 -package directory-1.2.0.1 -package
>> filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP
>> -XForeignFunctionInterface -no-user-package-db -rtsopts -odir
>> utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
>> utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o
>> utils/hsc2hs/dist/build/C.o
>>
>>
>> utils/hsc2hs/C.hs:155:3:
>>
>> parse error (possibly incorrect indentation or mismatched brackets)
>>
>>
>> There seem to be two classes of error: one is the layout issue above, but
>> other files can be fixed by simply running 'expand' on them.
>>
>>
>> On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini wrote:
>>
>>> 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.step...@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 >>>> <mailto:lukex...@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")
>>>>>
>>>>>
>>
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
OK! So just to summarize: Building GHC HEAD with LLVM 3.0 or 3.2 (using GHC 7.6.3 as the bootstrap) on OS X 10.9 DP5/Xcode 5 DP5 exhibits very strange behavior wherein layout-based code along with mixed-tabs-and-spaces code fails to parse correctly, with issues in hundreds of files in the GHC HEAD tree. I don't have a 10.8 machine to check if this is a 10.9 exclusive issue, so I'd love if someone can try using these binaries to build GHC HEAD: http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz Building GHC HEAD with LLVM 3.3 or 3.4 works great as a regular compiler with the 10.9 workarounds I outlined in another thread, but fails when compiling as a cross-compiler (./configure --target=arm-apple-darwin10) with these errors: https://gist.github.com/lukexi/2b129f34fa027172c5ee So I'm between a rock and a hard place at the moment. The only (very tedious and slow) workaround I've found for the 3.0/3.2 bug is to manually expand tabs to spaces, and to transform do x y into do x y (similarly for where and let blocks) Cheers Luke On Sun, Aug 11, 2013 at 1:53 AM, Luke Iannini wrote: > Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 > do not. > > > On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini wrote: > >> Further investigation: >> >> I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but >> the problem still occurred. >> >> The problem only occurs with LLVM 3.0. >> >> It is not related to cross-compilation or Stephen's patches: I tested >> this on multiple fresh clones with --with-gcc=clang. >> >> LLVM 3.2, 3.3 and 3.4 do not exhibit the issue. >> >> If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries >> here Clang Binaries for MacOS >> X/x86-64<http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz> >> and >> just drop them in your path. >> >> (Stephen, I'm now trying your patch with LLVM 3.2) >> >> Cheers >> Luke >> >> >> On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini wrote: >> >>> The first error on a fresh checkout is >>> >>> "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O >>> -package-db libraries/bootstrapping.conf -hide-all-packages -i >>> -iutils/hsc2hs/. -iutils/hsc2hs/dist/build >>> -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build >>> -Iutils/hsc2hs/dist/build/autogen -optP-include >>> -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 >>> -package containers-0.5.0.0 -package directory-1.2.0.1 -package >>> filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP >>> -XForeignFunctionInterface -no-user-package-db -rtsopts -odir >>> utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir >>> utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o >>> utils/hsc2hs/dist/build/C.o >>> >>> >>> utils/hsc2hs/C.hs:155:3: >>> >>> parse error (possibly incorrect indentation or mismatched brackets) >>> >>> >>> There seem to be two classes of error: one is the layout issue above, >>> but other files can be fixed by simply running 'expand' on them. >>> >>> >>> On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini wrote: >>> >>>> 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.step...@blacksapphire.com> wrote: >>>> >>>>> Luke, >>>>> >>>>> Try llvm version 3.0 - that's what I'm using, and it definitely worked >>>>>
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
And the truly final word for the moment : ) — I built a tool to partially automate the indentation workaround for LLVM 3.0 and it yields the same "co-processor offset out of range"/"unsupported relocation on symbol LCPI65_0" errors LLVM 3.3/3.4 did when it finally gets to integer-simple/GHC/Integer/Type.hs. On Sun, Aug 11, 2013 at 3:06 AM, Luke Iannini wrote: > OK! So just to summarize: > Building GHC HEAD with LLVM 3.0 or 3.2 (using GHC 7.6.3 as the bootstrap) > on OS X 10.9 DP5/Xcode 5 DP5 exhibits very strange behavior wherein > layout-based code along with mixed-tabs-and-spaces code fails to parse > correctly, with issues in hundreds of files in the GHC HEAD tree. > I don't have a 10.8 machine to check if this is a 10.9 exclusive issue, so > I'd love if someone can try using these binaries to build GHC HEAD: > http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz > > Building GHC HEAD with LLVM 3.3 or 3.4 works great as a regular compiler > with the 10.9 workarounds I outlined in another thread, but fails when > compiling as a cross-compiler (./configure --target=arm-apple-darwin10) > with these errors: > https://gist.github.com/lukexi/2b129f34fa027172c5ee > > So I'm between a rock and a hard place at the moment. > > The only (very tedious and slow) workaround I've found for the 3.0/3.2 bug > is to manually expand tabs to spaces, and to transform > do x >y > into > do > x > y > (similarly for where and let blocks) > > Cheers > Luke > > > On Sun, Aug 11, 2013 at 1:53 AM, Luke Iannini wrote: > >> Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 >> do not. >> >> >> On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini wrote: >> >>> Further investigation: >>> >>> I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but >>> the problem still occurred. >>> >>> The problem only occurs with LLVM 3.0. >>> >>> It is not related to cross-compilation or Stephen's patches: I tested >>> this on multiple fresh clones with --with-gcc=clang. >>> >>> LLVM 3.2, 3.3 and 3.4 do not exhibit the issue. >>> >>> If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries >>> here Clang Binaries for MacOS >>> X/x86-64<http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz> >>> and >>> just drop them in your path. >>> >>> (Stephen, I'm now trying your patch with LLVM 3.2) >>> >>> Cheers >>> Luke >>> >>> >>> On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini wrote: >>> >>>> The first error on a fresh checkout is >>>> >>>> "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O >>>> -package-db libraries/bootstrapping.conf -hide-all-packages -i >>>> -iutils/hsc2hs/. -iutils/hsc2hs/dist/build >>>> -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build >>>> -Iutils/hsc2hs/dist/build/autogen -optP-include >>>> -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 >>>> -package containers-0.5.0.0 -package directory-1.2.0.1 -package >>>> filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP >>>> -XForeignFunctionInterface -no-user-package-db -rtsopts -odir >>>> utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir >>>> utils/hsc2hs/dist/build -c utils/hsc2hs/./C.hs -o >>>> utils/hsc2hs/dist/build/C.o >>>> >>>> >>>> utils/hsc2hs/C.hs:155:3: >>>> >>>> parse error (possibly incorrect indentation or mismatched brackets) >>>> >>>> >>>> There seem to be two classes of error: one is the layout issue above, >>>> but other files can be fixed by simply running 'expand' on them. >>>> >>>> >>>> On Sat, Aug 10, 2013 at 6:42 PM, Luke Iannini wrote: >>>> >>>>> 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 an
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
Hi all, I tried this — building GHC HEAD configured to use the native code gen, and then building the cross compiler using that, and got the same errors as everything else thus far: https://gist.github.com/lukexi/02366ed57171400b961a 10.9 Mavericks is likely coming out in less than a month, along with iOS7 and Xcode5 final, so it's definitely worth sorting this out! Not quite sure what to try next though... Best Luke On Sun, Aug 11, 2013 at 3:18 PM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > What if you build a copy of head with the native code gen. Then build the > cross compiler using head on head? > > > On Sunday, August 11, 2013, Luke Iannini wrote: > >> And the truly final word for the moment : ) — >> I built a tool to partially automate the indentation workaround for LLVM >> 3.0 and it yields the same "co-processor offset out of range"/"unsupported >> relocation on symbol LCPI65_0" errors LLVM 3.3/3.4 did when it finally gets >> to integer-simple/GHC/Integer/Type.hs. >> >> >> On Sun, Aug 11, 2013 at 3:06 AM, Luke Iannini wrote: >> >> OK! So just to summarize: >> Building GHC HEAD with LLVM 3.0 or 3.2 (using GHC 7.6.3 as the bootstrap) >> on OS X 10.9 DP5/Xcode 5 DP5 exhibits very strange behavior wherein >> layout-based code along with mixed-tabs-and-spaces code fails to parse >> correctly, with issues in hundreds of files in the GHC HEAD tree. >> I don't have a 10.8 machine to check if this is a 10.9 exclusive issue, >> so I'd love if someone can try using these binaries to build GHC HEAD: >> http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz >> >> Building GHC HEAD with LLVM 3.3 or 3.4 works great as a regular compiler >> with the 10.9 workarounds I outlined in another thread, but fails when >> compiling as a cross-compiler (./configure --target=arm-apple-darwin10) >> with these errors: >> https://gist.github.com/lukexi/2b129f34fa027172c5ee >> >> So I'm between a rock and a hard place at the moment. >> >> The only (very tedious and slow) workaround I've found for the 3.0/3.2 >> bug is to manually expand tabs to spaces, and to transform >> do x >>y >> into >> do >> x >> y >> (similarly for where and let blocks) >> >> Cheers >> Luke >> >> >> On Sun, Aug 11, 2013 at 1:53 AM, Luke Iannini wrote: >> >> Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 >> do not. >> >> >> On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini wrote: >> >> Further investigation: >> >> I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but >> the problem still occurred. >> >> The problem only occurs with LLVM 3.0. >> >> It is not related to cross-compilation or Stephen's patches: I tested >> this on multiple fresh clones with --with-gcc=clang. >> >> LLVM 3.2, 3.3 and 3.4 do not exhibit the issue. >> >> If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries >> here Clang Binaries for MacOS >> X/x86-64<http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz> >> and >> just drop them in your path. >> >> (Stephen, I'm now trying your patch with LLVM 3.2) >> >> Cheers >> Luke >> >> >> On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini wrote: >> >> The first error on a fresh checkout is >> >> "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O >> -package-db libraries/bootstrapping.conf -hide-all-packages -i >> -iutils/hsc2hs/. -iutils/hsc2hs/dist/build >> -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build >> -Iutils/hsc2hs/dist/build/autogen -optP-include >> -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 >> -package containers-0.5.0.0 -package directory-1.2.0.1 -package >> filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP >> -XForeignFunctionInterface -no-user-package-db -rtsopts -odir >> utils/hsc2hs/dist/build -hid >> >> ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
Hello all! I'm extremely happy to report (thanks to invaluable help from Stephen) that my issues were my own dumb fault : ) — I was using LLVM 3.0's Clang but not its llc or opt. With some other tweaks to Stephen's above patch[1], we now have a perfectly working GHC-iOS on OS X 10.9 Mavericks. Hurray! Cheers Luke [1]Stephen's work: http://ghc.haskell.org/trac/ghc/ticket/8125 http://ghc.haskell.org/trac/ghc/ticket/8126 http://ghc.haskell.org/trac/ghc/ticket/8127 On Mon, Aug 12, 2013 at 1:44 AM, Luke Iannini wrote: > Hi all, > > I tried this — building GHC HEAD configured to use the native code gen, > and then building the cross compiler using that, and got the same errors as > everything else thus far: > https://gist.github.com/lukexi/02366ed57171400b961a > > 10.9 Mavericks is likely coming out in less than a month, along with iOS7 > and Xcode5 final, so it's definitely worth sorting this out! > Not quite sure what to try next though... > > Best > Luke > > > On Sun, Aug 11, 2013 at 3:18 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> What if you build a copy of head with the native code gen. Then build the >> cross compiler using head on head? >> >> >> On Sunday, August 11, 2013, Luke Iannini wrote: >> >>> And the truly final word for the moment : ) — >>> I built a tool to partially automate the indentation workaround for LLVM >>> 3.0 and it yields the same "co-processor offset out of range"/"unsupported >>> relocation on symbol LCPI65_0" errors LLVM 3.3/3.4 did when it finally gets >>> to integer-simple/GHC/Integer/Type.hs. >>> >>> >>> On Sun, Aug 11, 2013 at 3:06 AM, Luke Iannini wrote: >>> >>> OK! So just to summarize: >>> Building GHC HEAD with LLVM 3.0 or 3.2 (using GHC 7.6.3 as the >>> bootstrap) on OS X 10.9 DP5/Xcode 5 DP5 exhibits very strange behavior >>> wherein layout-based code along with mixed-tabs-and-spaces code fails to >>> parse correctly, with issues in hundreds of files in the GHC HEAD tree. >>> I don't have a 10.8 machine to check if this is a 10.9 exclusive issue, >>> so I'd love if someone can try using these binaries to build GHC HEAD: >>> http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz >>> >>> Building GHC HEAD with LLVM 3.3 or 3.4 works great as a regular compiler >>> with the 10.9 workarounds I outlined in another thread, but fails when >>> compiling as a cross-compiler (./configure --target=arm-apple-darwin10) >>> with these errors: >>> https://gist.github.com/lukexi/2b129f34fa027172c5ee >>> >>> So I'm between a rock and a hard place at the moment. >>> >>> The only (very tedious and slow) workaround I've found for the 3.0/3.2 >>> bug is to manually expand tabs to spaces, and to transform >>> do x >>>y >>> into >>> do >>> x >>> y >>> (similarly for where and let blocks) >>> >>> Cheers >>> Luke >>> >>> >>> On Sun, Aug 11, 2013 at 1:53 AM, Luke Iannini wrote: >>> >>> Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 >>> do not. >>> >>> >>> On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini wrote: >>> >>> Further investigation: >>> >>> I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but >>> the problem still occurred. >>> >>> The problem only occurs with LLVM 3.0. >>> >>> It is not related to cross-compilation or Stephen's patches: I tested >>> this on multiple fresh clones with --with-gcc=clang. >>> >>> LLVM 3.2, 3.3 and 3.4 do not exhibit the issue. >>> >>> If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries >>> here Clang Binaries for MacOS >>> X/x86-64<http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz> >>> and >>> just drop them in your path. >>> >>> (Stephen, I'm now trying your patch with LLVM 3.2) >>> >>> Cheers >>> Luke >>> >>> >>> On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini wrote: >>> >>> The first error on a fresh checkout is >>> >>> "/usr/local/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O >>> -package-db libraries/bootstrapping.conf -hide-all-packages -i >>> -iutils/hsc2hs/. -iutils/hsc2hs/dist/build >>> -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build >>> -Iutils/hsc2hs/dist/build/autogen -optP-include >>> -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 >>> -package containers-0.5.0.0 -package directory-1.2.0.1 -package >>> filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP >>> -XForeignFunctionInterface -no-user-package-db -rtsopts -odir >>> utils/hsc2hs/dist/build -hid >>> >>> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Announcing GHC iOS
I will tell Stephen! I've added iOS as Tier 2 — I bet we can find a sponsor for a buildbot down the line — and I've added myself while I wait to hear from Stephen. It looks like the mailto links on the wiki (e.g. the names in the Platform Maintainers section) aren't working, by the way: http://ghc.haskell.org/trac/ghc/wiki/CodeOwners. Cheers Luke On Fri, Aug 30, 2013 at 2:04 AM, Simon Peyton-Jones wrote: > Great. Please thank Stephen too.. I don’t have his email. > > ** ** > > Just go ahead and modify > > http://ghc.haskell.org/trac/ghc/wiki/CodeOwners > > http://ghc.haskell.org/trac/ghc/wiki/Platforms > > ** ** > > I assume iOS will become a tier-2 platform?**** > > ** ** > > Simon > > ** ** > > *From:* Luke Iannini [mailto:lukex...@gmail.com] > *Sent:* 30 August 2013 09:07 > *To:* Simon Peyton-Jones > *Cc:* Austin Seipp > > *Subject:* Re: [Haskell-cafe] Announcing GHC iOS > > ** ** > > Certainly! And I'd be happy to take on maintainership of GHC iOS if that's > what you mean — I've committed to a very large project using it so I'll be > maintaining it anyway : ). I'd guess Stephen would feel the same. > > ** ** > > And thanks so much for the kind words, it means the world! Thank you > infinitely for Haskell : ). > > ** ** > > Cheers > > Luke > > ** ** > > On Fri, Aug 30, 2013 at 12:32 AM, Simon Peyton-Jones < > simo...@microsoft.com> wrote: > > Should we update the “Platform maintainers” on > http://ghc.haskell.org/trac/ghc/wiki/TeamGHC**** > > or the list of supported platforms on > http://ghc.haskell.org/trac/ghc/wiki/Platforms? > > > > *From:* Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] *On Behalf > Of *Luke Iannini > *Sent:* 29 August 2013 21:56 > *To:* Haskell Cafe > *Subject:* Re: [Haskell-cafe] Announcing GHC iOS > > > > Stephen provided some more credits — thanks so much to all! > > > > Three connected projects concerning cross-compilation: > > > > *Registerised ARM support, added using David Terei's LLVM compiler back > end with Stephen Blackheath doing an initial ARMv5 version and LLVM patch > and Karel Gardas working on floating point support, ARMv7 compatibility and > LLVM headaches. Ben Gamari did work on the runtime linker for ARM. > > > > *General cross-compiling, with much work by Stephen Blackheath and Gabor > Greif (though many others have worked on this). > > > > *A cross-compiler for Apple iOS. iOS-specific parts were mostly Stephen > Blackheath with Luke Iannini on the Cabal patch, testing and supporting > infrastructure, also with assistance and testing by Miëtek Bak and Jonathan > Fischoff, and thanks to many others for testing; The iOS cross compiler was > started back in 2009 by Stephen Blackheath with funding from Ryan Trinkle > of iPwn Studios. > > > > Thanks to Ian Lynagh for making it easy for us with integration, makefile > refactoring and patience, and to David Terei for LLVM assistance. > > > > > > On Thu, Aug 29, 2013 at 1:43 PM, Luke Iannini wrote:* > *** > > Hi all! > > (in case you don't read /r/haskell : )) > > > > Stephen Blackheath and I are extremely happy to report that as of today, > GHC can natively build binaries for iOS devices and the iOS Simulator. > > > > You'll find everything you need here: > http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS > > > > The short of it is you can use "ghc-ios myFiles.hs" to get a universal > ARMv7/ARMv7s/i386 static library to drop straight into an Xcode project.** > ** > > > > Stephen's already working on some wonderful FRP-powered games, I'm working > on a project called SpaceTime that I'll announce shortly, and you may now > all begin creating insanely great iOS software using the finest language in > the world : ). > > > > Stephen deserves the lion's share of the credit for this project — it's > been over 3 years in the making! Many thanks to Maxwell Swadling for > generalizing static library builds into a -staticlib flag for GHC, Carter > Schonwald for compilation guidance, and the venerable Austin Seipp for > reviewing and merging our patches. > > > > ** ** > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Announcing GHC iOS
Hi Gabor! Yes, I believe that's still the case (we're working around it by using different prefixes for each architecture at the moment). And I think we should definitely do what you propose. I'll see if I can get a patch together shortly (or if someone already knows exactly what to do and wants to do it first, feel free! : )). Cheers Luke On Sat, Aug 31, 2013 at 4:50 AM, Gabor Greif wrote: > Hi Luke, devs, > > Just a quick question, as I haven't recently built a cross-compiler, > but I have noticed a problem with installation of cross-ghc last time. > > $ ls /lib/ghc-7.7.20130412 > > The problem is, that when someone installs a non-cross > compiler the same day, the cross-compiler's > libraries and executables get overwritten > by the non-cross installation :-( > > This probably also happens with release versions. > > Can you confirm this behaviour with HEAD? > > In case yes, should we consider adding a > cross-prefix, like employed in bin/ ? > > $ ls /bin/powerpc-montavista-linux-gnuspe-ghc-pkg-7.7.20130412 > > Of course all the links inside must be re-aligned accordingly. > > Cheers, > > Gabor > > > On 8/31/13, Luke Iannini wrote: > > I will tell Stephen! > > > > I've added iOS as Tier 2 — I bet we can find a sponsor for a buildbot > down > > the line — and I've added myself while I wait to hear from Stephen. It > > looks like the mailto links on the wiki (e.g. the names in the Platform > > Maintainers section) aren't working, by the way: > > http://ghc.haskell.org/trac/ghc/wiki/CodeOwners. > > > > Cheers > > Luke > > > > > > On Fri, Aug 30, 2013 at 2:04 AM, Simon Peyton-Jones > > wrote: > > > >> Great. Please thank Stephen too.. I don’t have his email. > >> > >> ** ** > >> > >> Just go ahead and modify > >> > >> http://ghc.haskell.org/trac/ghc/wiki/CodeOwners > >> > >> http://ghc.haskell.org/trac/ghc/wiki/Platforms > >> > >> ** ** > >> > >> I assume iOS will become a tier-2 platform? > >> > >> ** ** > >> > >> Simon > >> > >> ** ** > >> > >> *From:* Luke Iannini [mailto:lukex...@gmail.com] > >> *Sent:* 30 August 2013 09:07 > >> *To:* Simon Peyton-Jones > >> *Cc:* Austin Seipp > >> > >> *Subject:* Re: [Haskell-cafe] Announcing GHC iOS > >> > >> ** ** > >> > >> Certainly! And I'd be happy to take on maintainership of GHC iOS if > >> that's > >> what you mean — I've committed to a very large project using it so I'll > >> be > >> maintaining it anyway : ). I'd guess Stephen would feel the same. > >> > >> ** ** > >> > >> And thanks so much for the kind words, it means the world! Thank you > >> infinitely for Haskell : ). > >> > >> ** ** > >> > >> Cheers > >> > >> Luke > >> > >> ** ** > >> > >> On Fri, Aug 30, 2013 at 12:32 AM, Simon Peyton-Jones < > >> simo...@microsoft.com> wrote: > >> > >> Should we update the “Platform maintainers” on > >> http://ghc.haskell.org/trac/ghc/wiki/TeamGHC > >> > >> or the list of supported platforms on > >> http://ghc.haskell.org/trac/ghc/wiki/Platforms? > >> > >> > >> > >> *From:* Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] *On > Behalf > >> Of *Luke Iannini > >> *Sent:* 29 August 2013 21:56 > >> *To:* Haskell Cafe > >> *Subject:* Re: [Haskell-cafe] Announcing GHC iOS > >> > >> > >> > >> Stephen provided some more credits — thanks so much to all! > >> > >> > >> > >> Three connected projects concerning cross-compilation: > >> > >> > >> > >> *Registerised ARM support, added using David Terei's LLVM compiler back > >> end with Stephen Blackheath doing an initial ARMv5 version and LLVM > patch > >> and Karel Gardas working on floating point support, ARMv7 compatibility > >> and > >> LLVM headaches. Ben Gamari did work on the runtime linker for ARM. > >> > >> > >> > >> *General cross-compiling, with much work by Stephen Blackheath and Gabor > >> Greif (though many others have worked on this). > >> > >> > >> &
Re: [Haskell-cafe] Announcing GHC iOS
Thanks! This seems to do the trick wonderfully. -ghclibdir = $(libdir)/ghc-$(ProjectVersion) +ghclibdir = $(libdir)/$(CrossCompilePrefix)ghc-$(ProjectVersion) I've just done a clean build with this and it's working perfectly. On Sat, Aug 31, 2013 at 2:26 PM, Gabor Greif wrote: > On 8/31/13, Luke Iannini wrote: > > Hi Gabor! > > Yes, I believe that's still the case (we're working around it by using > > different prefixes for each architecture at the moment). And I think we > > should definitely do what you propose. I'll see if I can get a patch > > together shortly (or if someone already knows exactly what to do and > wants > > to do it first, feel free! : )). > > This is probably where one should start, > > https://github.com/ghc/ghc/blob/master/mk/install.mk.in#L108 > > but be careful with the 'if's in the makefile! > > Cheers, > > Gabor > > > > > > Cheers > > Luke > > > > > > On Sat, Aug 31, 2013 at 4:50 AM, Gabor Greif wrote: > > > >> Hi Luke, devs, > >> > >> Just a quick question, as I haven't recently built a cross-compiler, > >> but I have noticed a problem with installation of cross-ghc last time. > >> > >> $ ls /lib/ghc-7.7.20130412 > >> > >> The problem is, that when someone installs a non-cross > >> compiler the same day, the cross-compiler's > >> libraries and executables get overwritten > >> by the non-cross installation :-( > >> > >> This probably also happens with release versions. > >> > >> Can you confirm this behaviour with HEAD? > >> > >> In case yes, should we consider adding a > >> cross-prefix, like employed in bin/ ? > >> > >> $ ls /bin/powerpc-montavista-linux-gnuspe-ghc-pkg-7.7.20130412 > >> > >> Of course all the links inside must be re-aligned accordingly. > >> > >> Cheers, > >> > >> Gabor > >> > >> > >> On 8/31/13, Luke Iannini wrote: > >> > I will tell Stephen! > >> > > >> > I've added iOS as Tier 2 — I bet we can find a sponsor for a buildbot > >> down > >> > the line — and I've added myself while I wait to hear from Stephen. It > >> > looks like the mailto links on the wiki (e.g. the names in the > Platform > >> > Maintainers section) aren't working, by the way: > >> > http://ghc.haskell.org/trac/ghc/wiki/CodeOwners. > >> > > >> > Cheers > >> > Luke > >> > > >> > > >> > On Fri, Aug 30, 2013 at 2:04 AM, Simon Peyton-Jones > >> > wrote: > >> > > >> >> Great. Please thank Stephen too.. I don’t have his email. > >> >> > >> >> ** ** > >> >> > >> >> Just go ahead and modify > >> >> > >> >> http://ghc.haskell.org/trac/ghc/wiki/CodeOwners > >> >> > >> >> http://ghc.haskell.org/trac/ghc/wiki/Platforms > >> >> > >> >> ** ** > >> >> > >> >> I assume iOS will become a tier-2 platform? > >> >> > >> >> ** ** > >> >> > >> >> Simon > >> >> > >> >> ** ** > >> >> > >> >> *From:* Luke Iannini [mailto:lukex...@gmail.com] > >> >> *Sent:* 30 August 2013 09:07 > >> >> *To:* Simon Peyton-Jones > >> >> *Cc:* Austin Seipp > >> >> > >> >> *Subject:* Re: [Haskell-cafe] Announcing GHC iOS**** > >> >> > >> >> ** ** > >> >> > >> >> Certainly! And I'd be happy to take on maintainership of GHC iOS if > >> >> that's > >> >> what you mean — I've committed to a very large project using it so > >> >> I'll > >> >> be > >> >> maintaining it anyway : ). I'd guess Stephen would feel the same. > >> >> > >> >> ** ** > >> >> > >> >> And thanks so much for the kind words, it means the world! Thank you > >> >> infinitely for Haskell : ). > >> >> > >> >> ** ** > >> >> > >> >> Cheers > >> >> > >> >> Luke > >> >> > >> >> ** ** > >> >> > >> >> On Fri, Aug 30, 2013 at 12:32
Re: [Haskell-cafe] Announcing GHC iOS
Hi Dominick, Hm, this should have been fixed by http://ghc.haskell.org/trac/ghc/ticket/7700 . When you say you downloaded GHC, do you mean you cloned GHC HEAD (e.g. git clone git://git.haskell.org/ghc.git ?) — the patches have only just landed : ). Also can you give us an idea of what your build environment is? (OS version, Xcode version etc) Cheers Luke On Sun, Sep 1, 2013 at 4:32 PM, Dominick Samperi wrote: > Hi, > > I followed the instructions on the link, downloaded ghc, created build.mk, > etc., > and configured for ghc-ios-sim. But the make fails with the message below. > Tried installing terminfo (cabal install terminfo) but this didn't help... > > ghc $ make > ===--- building phase 0 > make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds > make[1]: Nothing to be done for `phase_0_builds'. > ===--- building phase 1 > make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds > "inplace/bin/ghc-cabal" check utils/ghc-pkg > A 'license-file' is not specified. > "inplace/bin/ghc-cabal" configure utils/ghc-pkg dist-install "" > --with-ghc="/Users/dsamperi/ > bin/ghc/ghc/inplace/bin/ghc-stage1" > --with-ghc-pkg="/Users/dsamperi/bin/ghc/ghc/inplace/bin/ghc-pkg" > --disable-library-for-ghci --disable-library-vanilla > --disable-library-profiling --disable-shared --configure-option=CFLAGS=" > -U__i686 -fno-stack-protector " --configure-option=LDFLAGS=" " > --configure-option=CPPFLAGS=" " > --configure-option=--host=i386-apple-darwin11 > --with-gcc="/Users/dsamperi/bin/ghc/ghc-ios-scripts-master/i386-apple-darwin11-gcc" > --with-ld="/Users/dsamperi/bin/ghc/ghc-ios-scripts-master/i386-apple-darwin11-ld" > --configure-option=--with-cc="/Users/dsamperi/bin/ghc/ghc-ios-scripts-master/i386-apple-darwin11-gcc" > --with-ar="/opt/local/bin/ar" --with-ranlib="ranlib" > --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" > Configuring ghc-pkg-6.9... > ghc-cabal: At least the following dependencies are missing: > terminfo -any > make[1]: *** [utils/ghc-pkg/dist-install/package-data.mk] Error 1 > make: *** [all] Error 2 > > > On Fri, Aug 30, 2013 at 5:04 AM, Simon Peyton-Jones > wrote: > >> Great. Please thank Stephen too.. I don’t have his email. >> >> ** ** >> >> Just go ahead and modify >> >> http://ghc.haskell.org/trac/ghc/wiki/CodeOwners >> >> http://ghc.haskell.org/trac/ghc/wiki/Platforms >> >> ** ** >> >> I assume iOS will become a tier-2 platform? >> >> ** ** >> >> Simon >> >> ** ** >> >> *From:* Luke Iannini [mailto:lukex...@gmail.com] >> *Sent:* 30 August 2013 09:07 >> *To:* Simon Peyton-Jones >> *Cc:* Austin Seipp >> *Subject:* Re: [Haskell-cafe] Announcing GHC iOS >> >> ** ** >> >> Certainly! And I'd be happy to take on maintainership of GHC iOS if >> that's what you mean — I've committed to a very large project using it so >> I'll be maintaining it anyway : ). I'd guess Stephen would feel the same. >> >> >> ** ** >> >> And thanks so much for the kind words, it means the world! Thank you >> infinitely for Haskell : ). >> >> ** ** >> >> Cheers >> >> Luke >> >> ** ** >> >> On Fri, Aug 30, 2013 at 12:32 AM, Simon Peyton-Jones < >> simo...@microsoft.com> wrote: >> >> Should we update the “Platform maintainers” on >> http://ghc.haskell.org/trac/ghc/wiki/TeamGHC >> >> or the list of supported platforms on >> http://ghc.haskell.org/trac/ghc/wiki/Platforms? >> >> >> >> *From:* Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] *On >> Behalf Of *Luke Iannini >> *Sent:* 29 August 2013 21:56 >> *To:* Haskell Cafe >> *Subject:* Re: [Haskell-cafe] Announcing GHC iOS >> >> >> >> Stephen provided some more credits — thanks so much to all! >> >> >> >> Three connected projects concerning cross-compilation: >> >> >> >> *Registerised ARM support, added using David Terei's LLVM compiler back >> end with Stephen Blackheath doing an initial ARMv5 version and LLVM patch >> and Karel Gardas working on floating point support, ARMv7 compatibility and >> LLVM headaches. Ben Gamari did work on the runtime linker for ARM. >> >> >> >> *General cross-compiling, with much work by Stephen Blackhe
Re: [Haskell-cafe] Announcing GHC iOS
I've added a ticket to trac with the patch (I don't have commit access) http://ghc.haskell.org/trac/ghc/ticket/8217 Cheers Luke On Mon, Sep 2, 2013 at 4:36 AM, Gabor Greif wrote: > On 9/1/13, Luke Iannini wrote: > > Thanks! > > > > This seems to do the trick wonderfully. > > -ghclibdir = $(libdir)/ghc-$(ProjectVersion) > > +ghclibdir = $(libdir)/$(CrossCompilePrefix)ghc-$(ProjectVersion) > > > > I've just done a clean build with this and it's working perfectly. > > Great! Do you plan to push this? (Please do!) > > Cheers, > > Gabor > > > > > > > On Sat, Aug 31, 2013 at 2:26 PM, Gabor Greif wrote: > > > >> On 8/31/13, Luke Iannini wrote: > >> > Hi Gabor! > >> > Yes, I believe that's still the case (we're working around it by using > >> > different prefixes for each architecture at the moment). And I think > we > >> > should definitely do what you propose. I'll see if I can get a patch > >> > together shortly (or if someone already knows exactly what to do and > >> wants > >> > to do it first, feel free! : )). > >> > >> This is probably where one should start, > >> > >> https://github.com/ghc/ghc/blob/master/mk/install.mk.in#L108 > >> > >> but be careful with the 'if's in the makefile! > >> > >> Cheers, > >> > >> Gabor > >> > >> > >> > > >> > Cheers > >> > Luke > >> > > >> > > >> > On Sat, Aug 31, 2013 at 4:50 AM, Gabor Greif > wrote: > >> > > >> >> Hi Luke, devs, > >> >> > >> >> Just a quick question, as I haven't recently built a cross-compiler, > >> >> but I have noticed a problem with installation of cross-ghc last > time. > >> >> > >> >> $ ls /lib/ghc-7.7.20130412 > >> >> > >> >> The problem is, that when someone installs a non-cross > >> >> compiler the same day, the cross-compiler's > >> >> libraries and executables get overwritten > >> >> by the non-cross installation :-( > >> >> > >> >> This probably also happens with release versions. > >> >> > >> >> Can you confirm this behaviour with HEAD? > >> >> > >> >> In case yes, should we consider adding a > >> >> cross-prefix, like employed in bin/ ? > >> >> > >> >> $ ls > /bin/powerpc-montavista-linux-gnuspe-ghc-pkg-7.7.20130412 > >> >> > >> >> Of course all the links inside must be re-aligned accordingly. > >> >> > >> >> Cheers, > >> >> > >> >> Gabor > >> >> > >> >> > >> >> On 8/31/13, Luke Iannini wrote: > >> >> > I will tell Stephen! > >> >> > > >> >> > I've added iOS as Tier 2 — I bet we can find a sponsor for a > >> >> > buildbot > >> >> down > >> >> > the line — and I've added myself while I wait to hear from Stephen. > >> >> > It > >> >> > looks like the mailto links on the wiki (e.g. the names in the > >> Platform > >> >> > Maintainers section) aren't working, by the way: > >> >> > http://ghc.haskell.org/trac/ghc/wiki/CodeOwners. > >> >> > > >> >> > Cheers > >> >> > Luke > >> >> > > >> >> > > >> >> > On Fri, Aug 30, 2013 at 2:04 AM, Simon Peyton-Jones > >> >> > wrote: > >> >> > > >> >> >> Great. Please thank Stephen too.. I don’t have his email. > >> >> >> > >> >> >> ** ** > >> >> >> > >> >> >> Just go ahead and modify > >> >> >> > >> >> >> http://ghc.haskell.org/trac/ghc/wiki/CodeOwners > >> >> >> > >> >> >> http://ghc.haskell.org/trac/ghc/wiki/Platforms > >> >> >> > >> >> >> ** ** > >> >> >> > >> >> >> I assume iOS will become a tier-2 platform? > >> >> >> > >> >> >> ** ** > >> >> >> > >> >> >> Simon &g
Re: GHC 7.8 release status
Hi Luite, Would we be able to adapt this to get generalized Template Haskell support for GHC iOS/cross compilation? Cheers Luke On Wed, Sep 4, 2013 at 6:09 PM, Luite Stegeman wrote: > I've updated the wiki page, expanding the descriptions and adding code > from the actual implementation: > http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks > An demo program that uses all hooks here: > https://gist.github.com/luite/6444273 > (I've listed the users (or proposers) of every hook, and how they use it, > Thomas / Edsko, can you check that they indeed do what you need?) > The patch is here: > > https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks.patch > > In addition to defining the heterogeneous map and the hooks themselves, > extra exports have been added to make it possible for users to actually > make a hook implementation without copying most of the module's source > code. The demo program implements all hooks to check this. > > Also the GHCJS patch is here: > > > https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch > > It adds the following: > - in DynFlags an extra WayCustom constructor to add a custom 'tag' to > generated files (GHCJS builds multiple architectures to support Template > Haskell among other things, one with the 'js' tag) > - in ForeignCall the JavaScriptCallConv calling convention > - in Platform an ArchJavaScript architecture > - `foreign import javascript' support in the parser and lexer > - The JavaScriptFFI extension that enables the `foreign import javascript' > syntax, only supported on ArchJavaScript (So using it on a regular GHC > would always result in a compile error saying that it's unsupported on the > user's platform) > > luite > > > On Thu, Sep 5, 2013 at 12:17 AM, Thomas Schilling > wrote: > >> I started a wiki page at: http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks >> >> Luite: could you please fill in the hooks that your latest patch defines? >> >> >> On 4 Sep 2013, at 19:40, Simon Peyton-Jones >> wrote: >> >> > I do need more than a patch, please, please. A wiki page explaining >> the design, as seen by the user (of the GHC API), the problems it solves, >> and the use-cases it enables, would be most helpful. >> > >> > Simon >> > >> > | -Original Message- >> > | From: Thomas Schilling [mailto:nomin...@googlemail.com] >> > | Sent: 04 September 2013 17:26 >> > | To: Simon Peyton-Jones; Luite Stegeman >> > | Cc: Nicolas Frisby; "Pedro Magalhães (drei...@gmail.com)"; Richard >> > | Eisenberg (e...@cis.upenn.edu); Geoffrey Mainland >> > | (mainl...@cs.drexel.edu); Iavor Diatchki; Austin Seipp; Edsko de >> Vries; >> > | Ryan Newton (rrnew...@gmail.com); David Luposchainsky; ghc- >> > | d...@haskell.org >> > | Subject: Re: GHC 7.8 release status >> > | >> > | >> > | On 4 Sep 2013, at 15:52, Simon Peyton-Jones >> > | wrote: >> > | >> > | > Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be >> > | jolly soon. At the moment I don't even know the motivation or design, >> > | let alone implementation. Could you make a wiki page explaining the >> > | proposed design? Is it really important to do this for 7.8? >> > | >> > | Yes, it is quite important to get this into 7.8. Not having these >> > | features in GHC makes it very difficult for people to adopt GHCJS. >> One >> > | could argue that GHCJS is not yet production-ready anyway and users >> that >> > | want to try it can figure out building GHC from source to use it, but >> > | this doesn't quite apply. >> > | >> > | 1. GHCJS targets a wider audience than users brave enough to compile >> > | GHC from source. In addition, the next chance to get these features >> into >> > | GHC is in a year from now, so when GHCJS becomes more mature then this >> > | will be a major hurdle for adoption. >> > | >> > | 2. These changes are also required for IDE tools which really mustn't >> > | require users to build a custom version of GHC. >> > | >> > | >> > | Luite's design is actually very flexible. It simply allows GHC API >> > | users to provide functions that are called instead of (or in addition >> > | to) existing functions in GHC. Instead of calling, say, >> "genHardCode", >> > | the driver now looks up whether the user has specified a hook for >> > | genHardCode and calls that instead. >> > | >> > | Currently we only specify a small number of hooks that are sufficient >> > | for our use cases. Future releases of GHC can be extended to include >> > | more hooks, if that is needed. >> > | >> > | Hooks are stored as an untyped map inside the DynFlags (to avoid >> issues >> > | with circular dependencies). Each hook is looked up using a single- >> > | constructor type and type families are used to make this type safe. >> > | There is one use of unsafeCoerce to avoid having to make every hook >> > | function an instance of Typeable. >> > | >> > | Unlike CorePlugins, it is only a GHC API feature, and users cannot >> > | specify plugins to be added via command line
"has no symbols"/"same member name" warnings using libtool
Hi all, I'm trying to track down the last warnings in GHC iOS. We get this waterfall of warnings like: warning same member name (Types.o) in output file used for input files: /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(Types.o) and: /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(Types.o) due to use of basename, truncation and blank padding and file: /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(consUtils.o) has no symbols when we run libtool to create the static libraries, and I was wondering if anyone had any ideas what causes them so I could start debugging... I can't seem to find much information about the warning. Here's the output of i386-apple-darwin11-ghc -staticlib test.'s where test.hs is simply: main = print "hello world" https://gist.github.com/lukexi/25bfb42616933b0f1542 and here's the same with -v3 https://gist.github.com/lukexi/c1fbbe32cef9e3965a72 I suppose I can simply suppress the output of libtool when we call it from GHC, but I'd love to find the root cause if we can. Thanks for any hints! Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: "has no symbols"/"same member name" warnings using libtool
Hi Austin, Awesome, thanks so much — that gives me a much better understanding and a good roadmap of how to fix it. I'll start looking into it. Edward, I'll do that, thanks! Cheers Luke On Sat, Sep 14, 2013 at 12:50 AM, Austin Seipp wrote: > The second results are self explanatory: in your build, a lot of those > object files are simply empty on your target. consUtils.o for example > only has symbols defined on Windows - ditto with Win32Utils.c. But > they are unconditionally included in the c-sources field of base, so > it'll throw empty object files in, no questions asked. These two > instances can probably be fixed by just moving the c-sources clause > under an 'if os(windows)' block. Fixing the remaining ones is probably > also pretty simple, but a little more refactoring: you'll need to > tweak rts/ghc.mk in order to not build those files, as part of > `rts_C_SRCS`. It is probably OK to just discriminate on whether we're > using Stage1Only, as to whether to include them (someone pipe up here > if I'm wrong.) > > The first one is more problematic to fix. Imagine I have an iOS > application, which is actually an app.a file. My application depends > on libA.a and libB.a - two separate libraries. libB is also a user of > libA. > > I link against -lA and -lB at compile time, and get this warning. Why? > Because app.a and libB.a *both* depend on libA.a. This confuses > libtool obviously (and in certain situations is very bad.) Of course > your situation is more confusing at a glance, because the two > libraries are the same! > > What this is telling me is that somehow, libtool is trying to pick up > two copies of base and shove them into the final file, and the symbol > names obviously conflict. But it's not clear to me why this is the > case. > > Perhaps try running with -keep-tmp-files and -v3, and after the > compile finishes, invoke 'libtool' with the -v flag to get some more > verbose information? > > > > On Sat, Sep 14, 2013 at 2:12 AM, Edward Z. Yang wrote: > > Hey Luke, > > > > Please file a bug. Add static001 as a failing test case which is > > producing these errors. > > > > Thanks, > > Edward > > > > Excerpts from Luke Iannini's message of Thu Sep 05 18:40:14 -0700 2013: > >> Hi all, > >> > >> I'm trying to track down the last warnings in GHC iOS. > >> > >> We get this waterfall of warnings like: > >> warning same member name (Types.o) in output file used for input files: > >> > /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(Types.o) > >> and: > >> > /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(Types.o) > >> due to use of basename, truncation and blank padding > >> > >> and > >> > >> file: > >> > /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(consUtils.o) > >> has no symbols > >> > >> when we run libtool to create the static libraries, and I was wondering > if > >> anyone had any ideas what causes them so I could start debugging... I > can't > >> seem to find much information about the warning. > >> > >> Here's the output of > >> i386-apple-darwin11-ghc -staticlib test.'s > >> where test.hs is simply: main = print "hello world" > >> https://gist.github.com/lukexi/25bfb42616933b0f1542 > >> and here's the same with -v3 > >> https://gist.github.com/lukexi/c1fbbe32cef9e3965a72 > >> > >> I suppose I can simply suppress the output of libtool when we call it > from > >> GHC, but I'd love to find the root cause if we can. > >> > >> Thanks for any hints! > >> Cheers > >> Luke > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wither Haskell Platform 2013.4.0.0
To briefly explain the issue with Xcode 5 and GHC 7.6.3, as it's really not that big: 7.6.3 passes "-x c" when running the c compiler in preprocessor mode. Clang requires "-x assembler-with-cpp" to be compatible with the GHC codebase. So the workaround Austin Seipp helped me cook up is to simply wrap clang, detect it's being run in preprocessor mode (i.e. look for the args "-E -undef -traditional"), and make sure it gets passed -x assembler-with-cpp. You can see the entirety of it here: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/clang-xcode5-wrapper.hs I wrote the workaround as a a Haskell script, but someone with basic bash-fu could easily write it as a shell script. 7.6.3's settings file just has to be pointed at that wrapper instead of directly at clang and then everything works flawlessly with Xcode 5's clang, on 10.8 and 10.9 alike. Cheers Luke On Mon, Oct 14, 2013 at 9:13 AM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > I guess my point is there's a number of work arounds that are easy for a > power user to support, but should NOT be the default setup or config > required for new users. > > Eg: brew also provides an installer for apple-gcc42 and you could then > point your ghc settings file to. > > That said, it's not a solution we probably want to encourage by default, > it definitely took me a while to cook up sane directions, and some of those > directions/approaches apparently become useless if you update to OS X 10.9. > (I think partly because the default C++ std libs on Mac shift, so you can't > easily build GCC on mavericks currently allegedly ) > > On Monday, October 14, 2013, Edward Kmett wrote: > >> As I do most of my development on a Mac I confess I currently live in >> fear of accidentally clicking on the XCode 5 upgrade button and winding up >> in an unsupported configuration. That makes me very leery of option C, >> where developers like me are treading on egg-shells around system updates >> for the next 6 months. >> >> -Edward >> >> >> >> On Sun, Oct 13, 2013 at 7:26 PM, Mark Lentczner > > wrote: >> >>> It wasn't my intention to open up the whole question of scheduled >>> releases. HP has a regular release schedule, and there were many good >>> discussions leading up to it. As for the timing of those releases, last >>> time we looked into this there was no good release time that worked for all >>> the common Linux distro's release schedules. Perhaps GNOME has figured this >>> one out - they release stable end of September and end of March. We could >>> aim to glide toward that. >>> >>> Back to this release: >>> >>> GHC 7.8 won't be ready for inclusion in an HP for quite some time. We >>> haven't even seen the first release yet! If it has stabilized by end of >>> February, then it could make it into the next HP (assuming we don't move >>> the schedule up to match GNOME). But I think realistically, one shouldn't >>> expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If >>> the community wants to see closer tracking, then we probably need to start >>> talking about a different way of producing GHC - with both stable and >>> experimental releases happening... when this idea has been raised in the >>> past, GHC central hasn't had the person-power to do it.]* >>> * >>> * >>> The next Mac OS X is indeed right around the corner (no official date >>> from Apple, just "this Autumn") - the GM release candidate of both OS X >>> Mavericks and Xcode 5 are already in developers (and my) hands. My >>> understanding is that current HP just won't work on it - which means we >>> really should get something out to support it. >>> >>> SO, back to concrete ideas: >>> >>> *A) Minor release* >>> >>> *• Minor rev:* since GHC and most packages haven't changed, and we >>> won't be adding anything, just roll it as normal now. >>> *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC >>> 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 >>> >>> *—or—* >>> *B) Delay release* >>> >>> *• New packages:* running the normal process, just a month late >>> >>> *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is >>> needed to support Xcode 5 >>> >>> *—or—* >>> *C) Skip a release* >>> >>> *• Go for 7.8:* push everyone (GHC central, library maintainers) to get >>> 7.8 stable ASAP >>> >>> *• Big Push for Packages:* use the time to push for a significant >>> increase in the packages in the Platform >>> >>> *• Release in March: *aiming to sync with GNOME, assuming they're on to >>> something! >>> >>> >>> As attractive as some aspects of C are, it leaves anyone with a Mac out >>> in the cold for six months: They either can't upgrade, or can't Haskell. >>> >>> A requires duplicate effort (mostly on my part), but is otherwise >>> mechanical... and not that exciting. >>> >>> B deviates from our schedule, but if GHC can roll a 7.6.4, might get us >>> an HP with some new packages. >>> >>> — Mark >>> >>> >>>
Xcode 5 support for GHC iOS
Hi all, Just wanted to let you know I've finished updating GHC iOS to support Xcode 5. The new scripts are at https://github.com/ghc-ios/ghc-ios-scripts/tree/xcode5 and you'll find updated instructions at http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS . Please let me know if you have any trouble! Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Xcode 5 support for GHC iOS
Hi Dominick! Yes, this should work swimmingly on the 5S in 32bit mode. We'll have to wait for Apple to merge their Arm64 patches [1] before we can add full 64-bit support (I can do the 64bit simulator right now though : )). (though I just saw this! [2]) Cheers Luke [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September/065480.html [2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September/065913.html On Wed, Oct 16, 2013 at 8:16 AM, Dominick Samperi wrote: > Will this work with the new iPhone 5 S (64 bit ARM)? I assume that > it will work by running in 32 bit mode (requiring both 64 and 32 bit > libs to be loaded), but I'm not sure... > > Thanks, > Dominick > > > On Mon, Oct 14, 2013 at 3:48 PM, Luke Iannini wrote: > >> Hi all, >> >> Just wanted to let you know I've finished updating GHC iOS to support >> Xcode 5. The new scripts are at >> https://github.com/ghc-ios/ghc-ios-scripts/tree/xcode5 and you'll find >> updated instructions at >> http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS . >> >> Please let me know if you have any trouble! >> Cheers >> Luke >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Xcode 5 support for GHC iOS
Yeah, probably a data layout in compiler/llvmGen/LlvmCodeGen/Ppr.hs and entries in compiler/utils/Platform.hs? Shouldn't be too bad I think. On Thu, Oct 17, 2013 at 11:36 PM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > don't we need to add an ARM64 ABI to ghc/llvm? or is that a nonissue? > > > On Fri, Oct 18, 2013 at 2:34 AM, Luke Iannini wrote: > >> Hi Dominick! >> >> Yes, this should work swimmingly on the 5S in 32bit mode. >> >> We'll have to wait for Apple to merge their Arm64 patches [1] before we >> can add full 64-bit support (I can do the 64bit simulator right now though >> : )). (though I just saw this! [2]) >> >> Cheers >> Luke >> >> [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September/065480.html >> [2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September/065913.html >> >> >> On Wed, Oct 16, 2013 at 8:16 AM, Dominick Samperi wrote: >> >>> Will this work with the new iPhone 5 S (64 bit ARM)? I assume that >>> it will work by running in 32 bit mode (requiring both 64 and 32 bit >>> libs to be loaded), but I'm not sure... >>> >>> Thanks, >>> Dominick >>> >>> >>> On Mon, Oct 14, 2013 at 3:48 PM, Luke Iannini wrote: >>> >>>> Hi all, >>>> >>>> Just wanted to let you know I've finished updating GHC iOS to support >>>> Xcode 5. The new scripts are at >>>> https://github.com/ghc-ios/ghc-ios-scripts/tree/xcode5 and you'll find >>>> updated instructions at >>>> http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS . >>>> >>>> Please let me know if you have any trouble! >>>> Cheers >>>> Luke >>>> >>>> ___ >>>> ghc-devs mailing list >>>> ghc-devs@haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>>> >>> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: build errors
Hi guys, This is more clang CPP funniness — I've patched this kind of thing before (e.g. https://ghc.haskell.org/trac/ghc/attachment/ticket/8445/fix-xcode5-cpp-errors.patch). Basically clang CPP can't handle the space before the open-paren, so it needs to be removed to be recognized and processed as a macro. Cheers Luke On Thu, Nov 28, 2013 at 1:23 AM, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 28.11.2013, 12:43 +0900 schrieb Kazu Yamamoto: > > I cannot build GHC head on Linux and Mac (Mavericks) today: > > > > compiler/typecheck/TcEvidence.lhs:152:16: > > Not in scope: data constructor `ASSERT2' > > > > compiler/typecheck/TcEvidence.lhs:174:5: > > Not in scope: data constructor `ASSERT2' > > > > compiler/typecheck/TcEvidence.lhs:489:15: > > Not in scope: data constructor `ASSERT2' > > > > compiler/typecheck/TcEvidence.lhs:712:5: > > Not in scope: data constructor `ASSERT2' > > make[1]: *** [compiler/stage1/build/TcEvidence.o] Error 1 > > make[1]: *** Waiting for unfinished jobs > > make: *** [all] Error 2 > > these were added by me, but these are CPP macros that should be always > defined (in HsVersions.h). Also, the problem is not a general one, as > you can see on https://travis-ci.org/nomeata/ghc-complete/builds) > > Do you have any idea what might be unusual about your CPP setup? > > Greetings, > Joachim > > > -- > Joachim “nomeata” Breitner > m...@joachim-breitner.de • http://www.joachim-breitner.de/ > Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C > Debian Developer: nome...@debian.org > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
Hi Austin, all, FYI: I'm building GHC iOS binaries for RC1 right now. It would be awesome to release them along side if possible! Cheers Luke On Wed, Jan 29, 2014 at 6:28 AM, Kazu Yamamoto wrote: > Austin, > > > For the record, this error occurs fairly late in the ./validate script > > - it's for testing the in-place binary distribution after a build, but > > before the testsuite is run. In the mean time, you can just do 'cd > > testsuite && make fast' to run all your tests after you have seen this > > error. I simply do not have a sensible, easy fix right now. > > OK. I understand. > > P.S. > > I obtained Mac pro. Building and validating GHC on Mac pro are very > quick. So, if necessary, please feel free to ask me to check building > or validating GHC on Mac anytime. > > --Kazu > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
Hi Dominick, I've been using it every day for about 2 years on my primary project with great success -- I don't know if anyone's actually released anything into the store with it yet but I don't anticipate any problems whatsoever with Apple (I know many still think Apple doesn't allow other languages than ObjC/C/C++ but they actually lifted that policy years ago -- if the app works, they're happy : )). Cheers Luke On Wed, Jan 29, 2014 at 1:59 PM, Dominick Samperi wrote: > That is great Luke, > > I hope your work gets rolled into 7.8. > > Is this just "experimental," or is it possible to actually develop > an app that will pass Apple's QA and can be hosted on the > app store? Are there any examples currently hosted on the App Store? > > Thanks, > Dominick > > > On Wed, Jan 29, 2014 at 4:26 PM, Luke Iannini wrote: > > Hi Austin, all, > > > > FYI: I'm building GHC iOS binaries for RC1 right now. It would be > awesome to > > release them along side if possible! > > > > Cheers > > Luke > > > > > > On Wed, Jan 29, 2014 at 6:28 AM, Kazu Yamamoto wrote: > >> > >> Austin, > >> > >> > For the record, this error occurs fairly late in the ./validate script > >> > - it's for testing the in-place binary distribution after a build, but > >> > before the testsuite is run. In the mean time, you can just do 'cd > >> > testsuite && make fast' to run all your tests after you have seen this > >> > error. I simply do not have a sensible, easy fix right now. > >> > >> OK. I understand. > >> > >> P.S. > >> > >> I obtained Mac pro. Building and validating GHC on Mac pro are very > >> quick. So, if necessary, please feel free to ask me to check building > >> or validating GHC on Mac anytime. > >> > >> --Kazu > >> ___ > >> ghc-devs mailing list > >> ghc-devs@haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC for iOS (arm) 7.8 Preview Build ready for upload
Hi folks! I've just finished a preview build of GHC for iOS off the 7.8 branch, but could use a place to upload it. And once that's done, if anyone would like to help me test it that has Xcode 5 and a device, that would be excellent! Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC for iOS (arm) 7.8 Preview Build ready for upload
OK, it's up here now: https://github.com/ghc-ios/ghc-ios-scripts/releases/tag/7.8RC1Preview1 You'll need the scripts from https://github.com/ghc-ios/ghc-ios-scripts in your path along with LLVM 3.0 (it's the only version that works so far). On Wed, Jan 29, 2014 at 9:27 PM, Luke Iannini wrote: > Hi folks! > > I've just finished a preview build of GHC for iOS off the 7.8 branch, but > could use a place to upload it. > > And once that's done, if anyone would like to help me test it that has > Xcode 5 and a device, that would be excellent! > > Cheers > Luke > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
Hi Austin, Awesome. Builds are underway now. Cheers Luke On Thu, Jan 30, 2014 at 3:03 PM, Austin Seipp wrote: > (Grr, resending to list...) > > Hello all, > > The 7.8 branch is officially ready for RC1 (after some final Haddock > bugs got quickly squashed by Gergo and Mateusz.) > > Pali, Luke - this is specifically for you two as you have offered to > make the FreeBSD and iOS builds (Luke - 7.8 should contain both the > fix for __thread and the perf-cross flavor, so it should work out of > the box for you.) > > Attached is a fingerprint file for the GHC repository. You can restore it > with: > > $ ./utils/fingerprint/fingerprint.py restore -f ghc-7.8-rc1.fingerprint > > See here for more details - > > https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystate > > Alternatively, simply checking out to the 'ghc-7.8' branch will result > in the same thing - no new commits will go in until after RC1: > > $ git clone -b ghc-7.8 git://git.haskell.org/ghc ghc-7.8 > $ cd ghc-7.8 > $ ./sync-all get -b ghc-7.8 --extra --nofib > > Afterwords, just build and make the binaries as you normally would: > > $ ./boot; ./configure > $ make > $ make binary-dist > > Please let me know when the builds are done and somewhere to obtain > them, and I'll upload them to haskell.org for the RC. I'll begin my > builds now too... > > On Thu, Jan 30, 2014 at 5:02 PM, Austin Seipp wrote: > > Hello all, > > > > The 7.8 branch is officially ready for RC1 (after some final Haddock > > bugs got quickly squashed by Gergo and Mateusz.) > > > > Pali, Luke - this is specifically for you two as you have offered to > > make the FreeBSD and iOS builds (Luke - 7.8 should contain both the > > fix for __thread and the perf-cross flavor, so it should work out of > > the box for you.) > > > > Attached is a fingerprint file for the GHC repository. You can restore > it with: > > > > $ ./utils/fingerprint/fingerprint.py restore -f ghc-7.8-rc1.fingerprint > > > > See here for more details - > > > https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystate > > > > Alternatively, simply checking out to the 'ghc-7.8' branch will result > > in the same thing - no new commits will go in until after RC1: > > > > $ git clone -b ghc-7.8 git://git.haskell.org/ghc ghc-7.8 > > $ cd ghc-7.8 > > $ ./sync-all get -b ghc-7.8 --extra --nofib > > > > Afterwords, just build and make the binaries as you normally would: > > > > $ ./boot; ./configure > > $ make > > $ make binary-dist > > > > Please let me know when the builds are done and somewhere to obtain > > them, and I'll upload them to haskell.org for the RC. I'll begin my > > builds now too... > > > > > > On Thu, Jan 30, 2014 at 4:31 AM, Kazu Yamamoto wrote: > >> Hello Herbert, > >> > >>> Hello Kazu, > >>> > >>> ..as this is a Cabal issue, this needs to be handled upstream; could > you > >>> please file an issue at > >>> > >>> https://github.com/haskell/cabal/issues/new > >> > >> Done. > >> > >> https://github.com/haskell/cabal/issues/1660 > >> > >> --Kazu > >> ___ > >> ghc-devs mailing list > >> ghc-devs@haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > >> > > > > > > > > -- > > Regards, > > Austin - PGP: 4096R/0x91384671 > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
And I've placed the iOS simulator and device builds here: https://github.com/ghc-ios/ghc-ios-scripts/releases https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8RC1Preview1/ghc-7.8.20140129-arm-apple-ios.tar.bz2 and https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8RC1Previewi386/ghc-7.8.20140130-i386-apple-ios.tar.bz2 README coming up shortly. On Thu, Jan 30, 2014 at 6:29 PM, Páli Gábor János wrote: > On Fri, Jan 31, 2014 at 12:02 AM, Austin Seipp wrote: > > Please let me know when the builds are done and somewhere to obtain > > them, and I'll upload them to haskell.org for the RC. I'll begin my > > builds now too... > > All right, I have put the 32-bit and 64-bit FreeBSD builds here: > >http://haskell.inf.elte.hu/ghc/ > > Note that I included the corresponding SHA-256 checksum as well. > Also, I composed a brief README for the users on how to install and > use the binary distributions. > > Let me know if there is anything else I can do. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 branch is created, HEAD is now open, and a note on merges
Hm, these don't seem to have come together correctly. It looks like "make binary-dist" isn't ready for a stage1/cross-compiler... has anyone tried that before? Maybe someone can see what's wrong from the binaries. I'll start digging in now... Cheers Luke On Thu, Jan 30, 2014 at 7:06 PM, Luke Iannini wrote: > And I've placed the iOS simulator and device builds here: > https://github.com/ghc-ios/ghc-ios-scripts/releases > > > https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8RC1Preview1/ghc-7.8.20140129-arm-apple-ios.tar.bz2 > > and > > > https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8RC1Previewi386/ghc-7.8.20140130-i386-apple-ios.tar.bz2 > > README coming up shortly. > > > On Thu, Jan 30, 2014 at 6:29 PM, Páli Gábor János wrote: > >> On Fri, Jan 31, 2014 at 12:02 AM, Austin Seipp wrote: >> > Please let me know when the builds are done and somewhere to obtain >> > them, and I'll upload them to haskell.org for the RC. I'll begin my >> > builds now too... >> >> All right, I have put the 32-bit and 64-bit FreeBSD builds here: >> >>http://haskell.inf.elte.hu/ghc/ >> >> Note that I included the corresponding SHA-256 checksum as well. >> Also, I composed a brief README for the users on how to install and >> use the binary distributions. >> >> Let me know if there is anything else I can do. >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC iOS make binary-dist
Hi folks, I'm all set to release binaries for GHC iOS (arm and i386 simulator), but didn't realize the "make binary-dist" machinery is broken for cross-compilers. I'm starting work on it but will be fumbling in the dark a bit so if anyone has any knowledge or link or ideas on where to look, I'd love to hear them! Here's the output of "make binary-dist" on a tree after a successful "make" for arm-apple-darwin10 (which will "make install" perfectly). http://lpaste.net/99475 Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC iOS make binary-dist
OK, I've made a bit of progress here. Again, I have very little understanding of the binary-dist system so I hope this isn't nonsense. The utils/ghc-cabal/dist-install/build/tmp/ghc-cabal and utils/ghc-pwd/dist-install/build/tmp/ghc-pwd executables have .a extensions, which is a bug, but more importantly are built for arm and thus can't be used. lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a: Mach-O executable arm lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a: Mach-O executable arm So I tried switching them to the inplace/bin/ghc-cabal and utils/ghc-pwd/dist-boot/ghc-pwd copies, respectively, with this patch: http://lpaste.net/99485 This let me build the .tar.gz without errors, and ./configure it fine, but make install fails here now. "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc" "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc-pkg" "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129" '' '/usr/local' '/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129' '/usr/local/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) http://lpaste.net/99486 (looks like a missing dash in the CrossCompilePrefix as well but that's a minor issue) Does this offer any clues? Cheers Luke On Tue, Feb 4, 2014 at 6:22 PM, Luke Iannini wrote: > Hi folks, > > I'm all set to release binaries for GHC iOS (arm and i386 simulator), but > didn't realize the "make binary-dist" machinery is broken for > cross-compilers. > > I'm starting work on it but will be fumbling in the dark a bit so if > anyone has any knowledge or link or ideas on where to look, I'd love to > hear them! > > Here's the output of "make binary-dist" on a tree after a successful > "make" for arm-apple-darwin10 (which will "make install" perfectly). > http://lpaste.net/99475 > > Cheers > Luke > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC iOS make binary-dist
Aha. Looks like the "target word size" is incorrect in the binary-dist version. Here's arm-apple-darwin10ghc --info (i.e., the binary-dist version) http://lpaste.net/99489 and here's arm-apple-darwin10-ghc --info (from a working 'make install'ed version) http://lpaste.net/99490 A bad settings file, I guess. I'll see if I can fix that... Cheers Luke On Tue, Feb 4, 2014 at 8:59 PM, Luke Iannini wrote: > OK, I've made a bit of progress here. > > Again, I have very little understanding of the binary-dist system so I > hope this isn't nonsense. > > The utils/ghc-cabal/dist-install/build/tmp/ghc-cabal and > utils/ghc-pwd/dist-install/build/tmp/ghc-pwd > executables have .a extensions, which is a bug, but more importantly are > built for arm and thus can't be used. > > lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file > utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a > utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a: Mach-O executable arm > > lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file > utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a > utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a: Mach-O executable arm > > So I tried switching them to the inplace/bin/ghc-cabal and > utils/ghc-pwd/dist-boot/ghc-pwd copies, respectively, with this patch: > http://lpaste.net/99485 > > This let me build the .tar.gz without errors, and ./configure it fine, but > make install fails here now. > "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install > "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc" > "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc-pkg" > "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129" '' '/usr/local' > '/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129' > '/usr/local/share/doc/ghc/html/libraries' NO > ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi > magic number mismatch: old/corrupt interface file? (wanted 33214052, got > 129742) > > http://lpaste.net/99486 > > (looks like a missing dash in the CrossCompilePrefix as well but that's a > minor issue) > > Does this offer any clues? > > Cheers > Luke > > > On Tue, Feb 4, 2014 at 6:22 PM, Luke Iannini wrote: > >> Hi folks, >> >> I'm all set to release binaries for GHC iOS (arm and i386 simulator), but >> didn't realize the "make binary-dist" machinery is broken for >> cross-compilers. >> >> I'm starting work on it but will be fumbling in the dark a bit so if >> anyone has any knowledge or link or ideas on where to look, I'd love to >> hear them! >> >> Here's the output of "make binary-dist" on a tree after a successful >> "make" for arm-apple-darwin10 (which will "make install" perfectly). >> http://lpaste.net/99475 >> >> Cheers >> Luke >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC iOS make binary-dist
After fixing that, and the prefix missing a "-", I've got a working make install! Hurray! I'll tidy this up and make a patch. Cheers Luke On Tue, Feb 4, 2014 at 9:24 PM, Luke Iannini wrote: > Aha. Looks like the "target word size" is incorrect in the binary-dist > version. > Here's arm-apple-darwin10ghc --info (i.e., the binary-dist version) > http://lpaste.net/99489 > > and here's arm-apple-darwin10-ghc --info (from a working 'make install'ed > version) > http://lpaste.net/99490 > > A bad settings file, I guess. I'll see if I can fix that... > Cheers > Luke > > > On Tue, Feb 4, 2014 at 8:59 PM, Luke Iannini wrote: > >> OK, I've made a bit of progress here. >> >> Again, I have very little understanding of the binary-dist system so I >> hope this isn't nonsense. >> >> The utils/ghc-cabal/dist-install/build/tmp/ghc-cabal and >> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd >> executables have .a extensions, which is a bug, but more importantly are >> built for arm and thus can't be used. >> >> lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file >> utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a >> utils/ghc-cabal/dist-install/build/tmp/ghc-cabal.a: Mach-O executable arm >> >> lukexi@thopminkingscape:~/Code/ghc (ghc-7.8 *=)$ file >> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a >> utils/ghc-pwd/dist-install/build/tmp/ghc-pwd.a: Mach-O executable arm >> >> So I tried switching them to the inplace/bin/ghc-cabal and >> utils/ghc-pwd/dist-boot/ghc-pwd copies, respectively, with this patch: >> http://lpaste.net/99485 >> >> This let me build the .tar.gz without errors, and ./configure it fine, >> but make install fails here now. >> "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install >> "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc" >> "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129/bin/ghc-pkg" >> "/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129" '' '/usr/local' >> '/usr/local/lib/arm-apple-darwin10ghc-7.8.20140129' >> '/usr/local/share/doc/ghc/html/libraries' NO >> ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi >> magic number mismatch: old/corrupt interface file? (wanted 33214052, got >> 129742) >> >> http://lpaste.net/99486 >> >> (looks like a missing dash in the CrossCompilePrefix as well but that's a >> minor issue) >> >> Does this offer any clues? >> >> Cheers >> Luke >> >> >> On Tue, Feb 4, 2014 at 6:22 PM, Luke Iannini wrote: >> >>> Hi folks, >>> >>> I'm all set to release binaries for GHC iOS (arm and i386 simulator), >>> but didn't realize the "make binary-dist" machinery is broken for >>> cross-compilers. >>> >>> I'm starting work on it but will be fumbling in the dark a bit so if >>> anyone has any knowledge or link or ideas on where to look, I'd love to >>> hear them! >>> >>> Here's the output of "make binary-dist" on a tree after a successful >>> "make" for arm-apple-darwin10 (which will "make install" perfectly). >>> http://lpaste.net/99475 >>> >>> Cheers >>> Luke >>> >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
ghc-ios 7.8 working build
Hi all, I believe I've worked around the issues with make binary-dist and cross-compilation. This should be a working binary for iOS devices https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2 Please try ./configure && make install (it should live happily next to your current ghc as arm-apple-darwin10-ghc) and let me know so we can have a build ready for 7.8 RC2! Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc-ios 7.8 working build
Hi Dominick and all, That's great news! I've created a README here: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Note that the binary posted above is only for the device. I'll post the simulator version shortly along with instructions on how to create fat libraries that contain both simulator and device code. Please let me know if you have any questions or issues! Very best Luke On Tue, Feb 4, 2014 at 11:35 PM, Dominick Samperi wrote: > Hello Luke, > > It installed without problems under Mac OS X Mavericks and reports the > version correctly. If there is some documentation that you can point me to > I will test on my simulator and iPhone. > > Thanks, > Dominick > > > On Wed, Feb 5, 2014 at 1:36 AM, Luke Iannini wrote: > > Hi all, > > > > I believe I've worked around the issues with make binary-dist and > > cross-compilation. > > > > This should be a working binary for iOS devices > > > https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2 > > > > Please try ./configure && make install (it should live happily next to > your > > current ghc as arm-apple-darwin10-ghc) and let me know so we can have a > > build ready for 7.8 RC2! > > > > Cheers > > Luke > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ghc-ios 7.8 working build
Hi Dominick,
Awesome. Sounds like everything's working perfectly : ). The 'has no
symbols' messages are normal and harmless; I think they can be fixed but in
the meantime there is a script in ghc-ios-scripts called "libtool-quiet"
that silences them. You can use it by adding -pgmlibtool libtool-quiet to
your GHC arguments.
The output just goes to the iPhone's console which is normally shown in
Xcode when you run, but you can also access it with Apple's "iPhone
Configurator" app.
https://itunes.apple.com/us/app/apple-configurator/id434433123?mt=12 .
(You could also modify the example to return e.g. an Int and put that on
the screen with a UILabel or similar -- you can call Haskell from anywhere
in your app as long as you've called hs_init at the very beginning. A nice
trick is to create an NSObject category with a + (void)load { hs_init(NULL,
NULL) } method, which will ensure hs_init is called very early in your
program and then you don't have to worry about it anymore.)
Thanks so much for testing!
Cheers
Luke
On Wed, Feb 5, 2014 at 10:22 AM, Dominick Samperi wrote:
> [Luke: forgot to forward to list, sorry for the duplicates]
>
> There are two issues:
>
> 1. When I build Counter.a I see lots of messages from libtool saying
> "has no symbols",
> for example:
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool:
> for architecture: armv7s file:
>
> /usr/local/lib/arm-apple-darwin10-ghc-7.8.20140129/rts-1.0/libHSrts_thr.a(Sanity.thr_o)
> has no symbols
>
> 2. I have not (yet) joined the developer program since I have no plans to
> deploy
> to the app store, so instead I have been following the
> instructions here to deploy
> to my own device:
>
> http://www.sysrage.net/guides/ios-programming/building-and-running-ios-applications-without-a-paid-developer-license
>
> Following these instructions I am able to copy HaskellCounter (my name for
> your test app) to my device, and I see the HaskellCounter icon, but when I
> start the app I just see a blank screen. Looking at
>
> Counter.hs this is not too surprising, as I see no code that would update
> the
> Single View screen? I'm not sure where the output of putStrLn goes when
> an app is run on the device.
>
> Dominick
>
>
> On Wed, Feb 5, 2014 at 4:27 AM, Luke Iannini wrote:
> > Hi Dominick and all,
> >
> > That's great news!
> >
> > I've created a README here:
> > https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md
> >
> > Note that the binary posted above is only for the device. I'll post the
> > simulator version shortly along with instructions on how to create fat
> > libraries that contain both simulator and device code.
> >
> > Please let me know if you have any questions or issues!
> >
> > Very best
> > Luke
> >
> >
> > On Tue, Feb 4, 2014 at 11:35 PM, Dominick Samperi
> > wrote:
> >>
> >> Hello Luke,
> >>
> >> It installed without problems under Mac OS X Mavericks and reports the
> >> version correctly. If there is some documentation that you can point me
> to
> >> I will test on my simulator and iPhone.
> >>
> >> Thanks,
> >> Dominick
> >>
> >>
> >> On Wed, Feb 5, 2014 at 1:36 AM, Luke Iannini
> wrote:
> >> > Hi all,
> >> >
> >> > I believe I've worked around the issues with make binary-dist and
> >> > cross-compilation.
> >> >
> >> > This should be a working binary for iOS devices
> >> >
> >> >
> https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2
> >> >
> >> > Please try ./configure && make install (it should live happily next to
> >> > your
> >> > current ghc as arm-apple-darwin10-ghc) and let me know so we can have
> a
> >> > build ready for 7.8 RC2!
> >> >
> >> > Cheers
> >> > Luke
> >> >
> >> > ___
> >> > ghc-devs mailing list
> >> > ghc-devs@haskell.org
> >> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >> >
> >
> >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
GHC iOS 7.8.1 RC1 for Device & Simulator
Hi folks, RC builds of GHC iOS are now ready for devices and the iOS simulator. https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device/ghc-7.8.20140129-arm-apple-ios.tar.bz2 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-simulator/ghc-7.8.20140130-i386-apple-ios.tar.bz2 You'll find complete instructions on their usage here, including compiling cabal packages: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Please let me know how it goes! Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RC2 release imminent
Hi Austin, Here are the GHC iOS builds. https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140226-arm-apple-ios.tar.bz2 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140226-arm-apple-ios.tar.bz2.sha1 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140226-i386-apple-ios.tar.bz2 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140226-i386-apple-ios.tar.bz2.sha1 Readme is here: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Cheers! Luke On Wed, Feb 26, 2014 at 11:32 PM, Páli Gábor János wrote: > 2014-02-27 1:14 GMT+01:00 Austin Seipp : > > Like last time, please include a link to the bindist, and a > > cryptographic hash (md5/sha1) of the tarball so I know it's OK. > > Here are the FreeBSD builds: > > http://haskell.inf.elte.hu/ghc/ > > Note that I have updated the checksum file and the README too. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RC2 release imminent
Quad linkage: https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140228-arm-apple-ios.tar.bz2 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-device/ghc-7.8.0.20140228-arm-apple-ios.tar.bz2.sha1 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140228-i386-apple-ios.tar.bz2 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc2-simulator/ghc-7.8.0.20140228-i386-apple-ios.tar.bz2.sha1 + readme https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Cheers Luke On Sat, Mar 1, 2014 at 12:29 AM, Páli Gábor János wrote: > 2014-03-01 0:46 GMT+01:00 Austin Seipp : > > New source distributions are available here: > > > > http://www.haskell.org/ghc/dist/7.8.1-rc2/ > > > > Feel free to build when you get a chance at attach the hashes for the > > binary dists. > > The corresponding FreeBSD build are available here: > > > http://haskell.inf.elte.hu/ghc/ghc-7.8.0.20140228-i386-portbld-freebsd.tar.bz2 > > http://haskell.inf.elte.hu/ghc/ghc-7.8.0.20140228-x86_64-portbld-freebsd.tar.bz2 > > Hashes: > > http://haskell.inf.elte.hu/ghc/SHA256SUMS > > Updated installation instructions: > > http://haskell.inf.elte.hu/ghc/README.html > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.1 plan
Hi Austin/all, Here's GHC iOS 7.8.1 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.1-device/ghc-7.8.1-arm-apple-ios.tar.bz2 (sha 4b98f55212b33296ed9d59d7e30eaa12d7a34a3b) https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.1/ghc-7.8.1-i386-apple-ios.tar.bz2 (sha bcd213b4da15f77aaa4b1b06c51867785f262002) and README https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Cheers Luke On Wed, Apr 9, 2014 at 6:09 PM, Austin Seipp wrote: > Jens, > > It's probably due to abb86adf7f749b3d44887d28bc96b43c5a1e0631[1] which > was merged post RC2. I base this on the fact your build is failing > during the dynamic build. Do try a reverse patch and see if it helps. > > I believe Karel is right - you just need to use Gold. Ben actually had > patches to make the build fail if using binutils ld was detected, but > I believe I had reservations about the patch which I cannot recall off > the top of my head. In any case, a fix like that can certainly go in > 7.8.2. > > Do let us know how it goes. > > [1] > https://github.com/ghc/ghc/commit/abb86adf7f749b3d44887d28bc96b43c5a1e0631 > > On Wed, Apr 9, 2014 at 8:03 PM, Jens Petersen > wrote: > > On 9 April 2014 17:53, Karel Gardas wrote: > >> > >> Ben Gamari (cced) documented it well here: > >> http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html > >> > >> Looks like the issue is caused by binutils' linker while fixed in gold. > > > > > > Thanks a lot, Karel! I will try Ben's hack later. > > > > I am still surprised that RC2 builds fine on ARM (I re-verified that > > yesterday [1]) but not final 7.8.1. > > Were there some late ARM or linking changes that cause this now? > > > >> On 04/ 9/14 10:21 AM, Jens Petersen wrote: > >>> > >>> dll-split: internal error: evacuate(static): strange closure type 0 > >> > >> > >>> > >>> See http://koji.fedoraproject.org/koji/taskinfo?taskID=6719940 for > > > > > >>> > >>> I reproduced this two times now. RC2 built okay on ARM so I am not > >>> sure what changed. > > > > > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6720331 > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.2 bugs and beyond
Hi Austin, Here are the iOS builds: https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.2-device/ghc-7.8.2-arm-apple-ios.tar.bz2 SHA1 2160c203ed641e38e1306a722727105db97ea7d7 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.2-simulator/ghc-7.8.2-i386-apple-ios.tar.bz2 SHA1 c855877d2b77a8c401da804373a3334e0dea43d4 & README https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md On Fri, Apr 11, 2014 at 11:39 PM, Kazu Yamamoto wrote: > Helo, > > > The 7.8.2 source tarball is here. I actually have most of the binaries > > ready, but I forgot to send this in advance: > > > > http://www.haskell.org/ghc/dist/7.8.2/ > > > > Please build when you get a chance. I'll probably go ahead and > > announce shortly to get the bugfix into peoples hands, and we can > > incrementally add new tarballs. > > Now I can build yesod with GHC 7.8.2 on my Mac. Thanks. > > --Kazu > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
ARM64 Task Force
Howdy all, Would anyone like to team up on getting ARM64 support into GHC? Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.3 source tarball imminent
Hi Austin/all, Here are the iOS builds! http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.bz2 http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.bz2.sha1 http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.xz http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.xz.sha1 http://tree.is/files/ghc-7.8.3-i386-apple-ios.tar.bz2 http://tree.is/files/ghc-7.8.3-i386-apple-ios.tar.bz2.sha1 http://tree.is/files/ghc-7.8.3-i386-apple-ios.tar.xz http://tree.is/files/ghc-7.8.3-i386-apple-ios.tar.xz.sha1 Best Luke On Thu, Jul 10, 2014 at 6:51 AM, Mark Lentczner wrote: > Morning all. I've just kicked off the Mac builds > > Since I have several to do, and they take awhile... and I have to go to > work today... I expect these to be ready sometime late tonight PST. > > - Mark > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.3 source tarball imminent
Hi Austin, Thanks! Should have mentioned that I updated the README and streamlined installation process for my class at BayHac. The new README is here if you'd like to pull it in: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md (raw: https://github.com/ghc-ios/ghc-ios-scripts/raw/master/README.md) Best Luke On Sat, Jul 12, 2014 at 2:54 PM, Austin Seipp wrote: > Thank you Luke. The binaries are uploaded and on the webpage. > > On Fri, Jul 11, 2014 at 9:54 PM, Luke Iannini wrote: > > Hi Austin/all, > > Here are the iOS builds! > > http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.bz2 > > http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.bz2.sha1 > > http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.xz > > http://tree.is/files/ghc-7.8.3-arm-apple-ios.tar.xz.sha1 > > > > http://tree.is/files/ghc-7.8.3-i386-apple-ios.tar.bz2 > > http://tree.is/files/ghc-7.8.3-i386-apple-ios.tar.bz2.sha1 > > http://tree.is/files/ghc-7.8.3-i386-apple-ios.tar.xz > > http://tree.is/files/ghc-7.8.3-i386-apple-ios.tar.xz.sha1 > > > > Best > > Luke > > > > > > > > On Thu, Jul 10, 2014 at 6:51 AM, Mark Lentczner < > mark.lentcz...@gmail.com> > > wrote: > >> > >> Morning all. I've just kicked off the Mac builds > >> > >> Since I have several to do, and they take awhile... and I have to go to > >> work today... I expect these to be ready sometime late tonight PST. > >> > >> - Mark > >> > >> ___ > >> ghc-devs mailing list > >> ghc-devs@haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > >> > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: msys2 64 bit: help help!
Congrats Simon : ) I use precisely the same machine! While I haven't run into that particular problem, I do use an alternative console that might provide a workaround in case you keep running into trouble: http://cmder.net/ My setup log is here, which explains how to use Cmder with MSYS2: https://gist.github.com/lukexi/e634067f1d7e3a629988#cmder All the best Luke On Mon, Jun 27, 2016 at 1:21 AM, David Macek wrote: > On 27. 6. 2016 10:01, Simon Peyton Jones via ghc-devs wrote: > > Friends, esp Tamar, > > > > I am in happy possession of a new Surface Book, running Windows 10, > which is delightful – except that I can’t make the msys64 installation > work, which is crucial for GHC. Can any of you help? > > > > ·I install it from here: > https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/, which seems > to be the canonical place. The actual 64-bit exe seems to be > msys2-x86_64-20160205.exe. > > > > ·Installation goes fine > > > > ·But when I launch the “MinGW-w54 Win64 shell” from the Start > menu, the screen flashes as if it is briefly putting up a window, but then > the window disappears. > > > > ·Each time I do this the task manager shows that there is > another running ‘mintty.exe’. But it has no visible window > > > > > > > > Does anyone have any idea what I can do or how I can investigate? I > can’t do any GHC development without this! > > Hi. > > Please try `C:\msys64\usr\bin\mintty.exe -h always -` (incl. the trailing > dash). You can also try `C:\msys64\usr\bin\bash.exe -li` in case the > culprit is really mintty. > > > -- > David Macek > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
