Closed Bug 1415726 Opened 8 years ago Closed 6 years ago

Intermittent ninja: build stopped: subcommand failed. after Linking CXX executable bin/llvm-tblgen

Categories

(Firefox Build System :: General, defect, P5)

Product:
Firefox Build System
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INACTIVE

People

(Reporter: aryx, Unassigned)

References

Details

(Keywords: intermittent-failure)

https://treeherder.mozilla.org/logviewer.html#?job_id=143117281&repo=mozilla-inbound [task 2017-11-08T20:16:43.616Z] [132/140] Linking CXX static library lib/libLLVMTableGen.a [task 2017-11-08T20:16:43.616Z] [133/140] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/SearchableTableEmitter.cpp.o [task 2017-11-08T20:16:43.616Z] [134/140] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/SubtargetEmitter.cpp.o [task 2017-11-08T20:16:43.616Z] [135/140] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86DisassemblerTables.cpp.o [task 2017-11-08T20:16:43.616Z] [136/140] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/TableGen.cpp.o [task 2017-11-08T20:16:43.616Z] [137/140] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86ModRMFilters.cpp.o [task 2017-11-08T20:16:43.616Z] [138/140] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86RecognizableInstr.cpp.o [task 2017-11-08T20:16:43.616Z] [139/140] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CTagsEmitter.cpp.o [task 2017-11-08T20:16:43.616Z] [140/140] Linking CXX executable bin/llvm-tblgen [task 2017-11-08T20:16:43.616Z] ninja: build stopped: subcommand failed. [task 2017-11-08T20:16:43.629Z] Traceback (most recent call last): [task 2017-11-08T20:16:43.629Z] File "./build-clang.py", line 551, in <module> [task 2017-11-08T20:16:43.629Z] build_type, assertions, python_path, gcc_dir, libcxx_include_dir) [task 2017-11-08T20:16:43.629Z] File "./build-clang.py", line 220, in build_one_stage [task 2017-11-08T20:16:43.629Z] build_package(build_dir, cmake_args) [task 2017-11-08T20:16:43.629Z] File "./build-clang.py", line 67, in build_package [task 2017-11-08T20:16:43.629Z] run_in(package_build_dir, ["ninja", "install"]) [task 2017-11-08T20:16:43.629Z] File "./build-clang.py", line 42, in run_in [task 2017-11-08T20:16:43.629Z] check_run(args) [task 2017-11-08T20:16:43.629Z] File "./build-clang.py", line 35, in check_run [task 2017-11-08T20:16:43.629Z] assert r == 0 [task 2017-11-08T20:16:43.629Z] AssertionError [taskcluster 2017-11-08 20:16:44.474Z] === Task Finished ===
[task 2017-11-08T20:16:40.606Z] /usr/bin/ranlib: 'lib/libLLVMSupport.a': No such file It's the same as bug 1414558, and suggests it was not an aufs problem after all.
Flags: needinfo?(gps)
So much for that shot in the dark. On the upside, at least we're no longer building on AUFS! This smells like a race condition bug in the upstream build system. I looked at a diff between 3.9.0 and 3.9.1 and there were no meaningful build system changes. Since we haven't seen this error outside the MacOS toolchain tasks (which build other versions of LLVM/Clang), perhaps this is a bug unique to 3.9 and/or cross-compiling. I'll keep the needinfo set to look through the LLVM project history and bug systems to see if there are any obvious patches we can cherry pick to fix the issue.
Note we're not building other versions on those cross builds. It could very well be a general and still existing problem with cross-building clang.
Given the infrequency of this and likely depth of the rabbit hole, I'm not inclined to go looking for the underlying bug at this time.
Flags: needinfo?(gps)
Product: Core → Firefox Build System
Priority: -- → P5
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.