Nixpkgs: llvm-7.0.1 fails tests on armv7

Created on 12 Mar 2019  Â·  6Comments  Â·  Source: NixOS/nixpkgs

Issue description

When trying to build llvm-7.0.1 on my armv7 machine, I get the following error during the test phase:

********************
Failing Tests (6):
    LLVM :: DebugInfo/X86/debug_addr.ll
    LLVM :: tools/llvm-dwarfdump/X86/debug_addr.s
    LLVM :: tools/llvm-dwarfdump/X86/debug_addr_address_size_mismatch.s
    LLVM :: tools/llvm-dwarfdump/X86/debug_addr_dwarf4.s
    LLVM :: tools/llvm-dwarfdump/X86/debug_addr_unsupported_version.s
    LLVM :: tools/llvm-dwarfdump/X86/debug_addr_version_mismatch.s

  Expected Passes    : 25790
  Expected Failures  : 161
  Unsupported Tests  : 1042
  Unexpected Failures: 6

Looking around, I see quite a few changes to llvm recently (also the aarch64 failure in #56245).

Ideas? Are these tests expected to fail?

Most helpful comment

If you're in the situation I was in, and are unable to rebuild your ARMv7 system because it has inexplicably decided it needs llvm 7.0.1 as part of that build when it didn't used to, you can add something along the lines of the following to your configuration.nix:

nixpkgs.overlays = [
  (self: super: {
    mesa_noglu = super.mesa_noglu.override {
      llvmPackages = self.llvmPackages_6;
    };
  })
];

You will have to adapt it for whichever package is pulling in the unbuildable LLVM, which you can discover by looking at the list of unbuildable packages that nixos-rebuild spits out at the end and finding the one immediately after LLVM. You can verify that it's the right one by checking all-packages.nix in the repo and seeing that its callPackage parameters specify llvmPackages_7.

All 6 comments

@dtzWill @FRidh, just because I know you know about these things.

I know armv7 isn't "really" supported, but this definitely used to work, so...

FWIW, I have tried to disable DebugInfo tests, using the method already used to disable other tests, like this:

diff --git a/pkgs/development/compilers/llvm/7/llvm.nix b/pkgs/development/compilers/llvm/7/llvm.nix
index 34f8a5478d1..c7b3716aa8d 100644
--- a/pkgs/development/compilers/llvm/7/llvm.nix
+++ b/pkgs/development/compilers/llvm/7/llvm.nix
@@ -91,6 +91,10 @@ in stdenv.mkDerivation (rec {
     rm unittests/Support/DynamicLibrary/DynamicLibraryTest.cpp
   '' + ''
     patchShebangs test/BugPoint/compile-custom.ll.py
+  '' + optionalString stdenv.hostPlatform.isAarch32 ''
+    substituteInPlace unittests/DebugInfo/DWARF/CMakeLists.txt \
+      --replace "DWARFDebugInfoTest.cpp" ""
+    rm unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
   '';

But this didn't do anything. I do not know the test system for llvm though, I just tried to identify which cpp file to remove by grepping around. So maybe this is not even one of the right files, or maybe I disabled it wrong.

I have not been able to find how to disable the llvm-dwarfdump tests, also.

Hints welcome, if you have any!

I am also able to reproduce these failures. I get the same list of failing tests as what's shown above.

Oh - in case it's not obvious to everybody, I should point out that these are x86-specific tests. Obviously they're supposed to work from any host architecture, but since most developers' machines are x86, I think it's entirely possible that somebody upstream introduced an unintended dependency on the host architecture. I've looked around a bit for any upstream bug report, but so far I haven't found one.

If you're in the situation I was in, and are unable to rebuild your ARMv7 system because it has inexplicably decided it needs llvm 7.0.1 as part of that build when it didn't used to, you can add something along the lines of the following to your configuration.nix:

nixpkgs.overlays = [
  (self: super: {
    mesa_noglu = super.mesa_noglu.override {
      llvmPackages = self.llvmPackages_6;
    };
  })
];

You will have to adapt it for whichever package is pulling in the unbuildable LLVM, which you can discover by looking at the list of unbuildable packages that nixos-rebuild spits out at the end and finding the one immediately after LLVM. You can verify that it's the right one by checking all-packages.nix in the repo and seeing that its callPackage parameters specify llvmPackages_7.

Thanks for the helpful workaround, @IreneKnapp!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

copumpkin picture copumpkin  Â·  3Comments

edolstra picture edolstra  Â·  3Comments

matthiasbeyer picture matthiasbeyer  Â·  3Comments

domenkozar picture domenkozar  Â·  3Comments

tomberek picture tomberek  Â·  3Comments