On Tue, Apr 01, 2014 at 02:49:51PM +0200, Joachim Breitner wrote: > Am Dienstag, den 01.04.2014, 13:16 +0100 schrieb Colin Watson: > > I've attached the arm64-specific parts of the current patch I'm working > > with, most of which are due to Karel Gardas. Assuming that I actually > > manage to build 7.6 (which is by no means a given), would it be > > acceptable to apply something like this patch set to the Debian > > packaging? > > Sure! Just let us know when you actually want it to be included.
Right, thanks. Continuing the saga here: http://www.haskell.org/pipermail/haskell-cafe/2014-April/113408.html > BTW, do you feel responsible for the existing armel architectures as > well? These are failing in GHC 7.8: > https://buildd.debian.org/status/package.php?p=ghc&suite=experimental Well, this is new to me, but it looks like this patch would do it for armhf: diff --git a/compiler/typecheck/TcSplice.lhs-boot b/compiler/typecheck/TcSplice.lhs-boot index c496aed..6cd8183 100644 --- a/compiler/typecheck/TcSplice.lhs-boot +++ b/compiler/typecheck/TcSplice.lhs-boot @@ -26,7 +26,9 @@ tcTypedBracket :: HsBracket Name -> TcRhoType -> TcM (HsExpr TcId) +#ifdef GHCI tcTopSpliceExpr :: Bool -> TcM (LHsExpr Id) -> TcM (LHsExpr Id) +#endif runQuasiQuoteDecl :: HsQuasiQuote RdrName -> TcM [LHsDecl RdrName] runQuasiQuoteExpr :: HsQuasiQuote RdrName -> TcM (LHsExpr RdrName) @@ -34,12 +36,12 @@ runQuasiQuoteType :: HsQuasiQuote RdrName -> TcM (LHsType RdrName) runQuasiQuotePat :: HsQuasiQuote RdrName -> TcM (LPat RdrName) runAnnotation :: CoreAnnTarget -> LHsExpr Name -> TcM Annotation +#ifdef GHCI runMetaE :: LHsExpr Id -> TcM (LHsExpr RdrName) runMetaP :: LHsExpr Id -> TcM (LPat RdrName) runMetaT :: LHsExpr Id -> TcM (LHsType RdrName) runMetaD :: LHsExpr Id -> TcM [LHsDecl RdrName] -#ifdef GHCI lookupThName_maybe :: TH.Name -> TcM (Maybe Name) runQuasi :: TH.Q a -> TcM a #endif I'm running a build test on harris; if that works then I'll send it upstream and push it to darcs. armel (which for the record I only care about in the sort of abstract way that I care about all architectures working) is a different matter. compiler/cbits/genSym.c is a new file in 7.8, and it uses atomic_inc. armel is our only architecture where the implementation of atomic_inc isn't entirely inline. I'm not sure of the proper fix, though; I suppose the compiler could link against libHSrts (maybe only when needed) but I have no idea whether that's reasonable. I've filed an upstream bug: https://ghc.haskell.org/trac/ghc/ticket/8951 -- Colin Watson [[email protected]] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
