Opened 3 years ago

Closed 3 years ago

#10292 closed bug (duplicate)

Validate fails on armhf-linux

Reported by: erikd Owned by:
Priority: normal Milestone: 7.10.2
Component: Compiler Version: 7.10.1
Keywords: Cc: bgamari
Operating System: Unknown/Multiple Architecture: arm
Type of failure: Building GHC failed Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

After apply the 'configure : LLVM and LD detection improvements' patch from #10234 validation of the ghc-7.10 branch fails with:

inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell \
  "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary \
  BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom \
  ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn \
  CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph \
  DriverPhases DynFlags Encoding ErrUtils Exception ExtsCompat46 \
  FamInstEnv FastFunctions FastMutInt FastString FastTypes Fingerprint \
  FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp \
  HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id \
  IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme ListSetOps Literal \
  Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName \
  OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair \
  Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames \
  PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags \
  StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep \
  TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var \
  VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls \
  CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils \
  CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 \
  CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin \
  CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 \
  FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm \
  PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure \
  StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils \
  StgSyn Stream"
compiler/ghc.mk:653: recipe for target 'compiler/stage2/dll-split.stamp' 
failed
make[1]: *** [compiler/stage2/dll-split.stamp] Segmentation fault

There have been a number of tickets related to dll-split on armhf. I have verified that the ld.gold linker is being invoked. The fixes introduced in #9873 also seem to be present.

More investigation needed.

Change History (7)

comment:1 Changed 3 years ago by rwbarton

dll-split crashing usually just means the stage2 compiler is broken somehow, it may be good to start by running the test suite.

comment:2 Changed 3 years ago by erikd

@rwbarton : With this failure to build dll-split the stage2 compiler isn't complete, so how do I run the test suite?

comment:3 Changed 3 years ago by rwbarton

If dll-split was built then the stage2 compiler has also been built, since dll-split is built with the stage2 compiler. It's just the dll-split check and perhaps some libraries that did not get built yet, but you can run the test suite without those.

comment:4 Changed 3 years ago by bgamari

Cc: bgamari added

comment:5 Changed 3 years ago by erikd

A checkout of the ghc-7.10 branch (commit f6c690ba64) with these cherry-picked commits:

5d5abdca31     llvmGen: move to LLVM 3.6 exclusively
56fbc18e13     Commit missing T10148 files and ignore the built executable.

and commit that fixes some configure.ac, aclocal.m4 and distrib/configure.ac.in issues does not suffer from this ddl-split issue.

This is also reminiscent of #9920 where the fix was to either patch the llvm-3.5 sources or move to llvm-3.6.

comment:6 Changed 3 years ago by erikd

Its seems to that @bgamari is is using llvm-3.5.1 where I have been using the llvm-3.5 package from Debian (which seems to be llvm-3.5.0 with about 30 patches applied). Since ticket #9920 actually has the arm-lower-tail-calls.patch patch as an attachment, that patch could probably be added the Debian's llvm package, but that doesn't solve the problem on non-Debian systems.

What we need now is a way to detect this llvm bug at configure time. I'm working on that.

comment:7 Changed 3 years ago by erikd

Resolution: duplicate
Status: newclosed

The patch to detect this at configure time is in #10329 and Phab:D856 .

Note: See TracTickets for help on using tickets.