<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 1, 2015 at 2:17 AM, David Chisnall via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 1 Dec 2015, at 10:03, 慕冬亮 via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> collect2: fatal error: ld terminated with signal 9 [Killed]<br>
> compilation terminated.<br>
> [2706/2983] Linking CXX executable bin/clang-check<br>
> ninja: build stopped: subcommand failed.<br>
<br>
</span>This looks like the linker is running out of memory.  This is a huge link job and BFD linker will consume at least one GB of RAM, possibly far more depending on your build config.  If you’re on a 32-bit platform, then you won’t be able to do this with a debug build.<br></blockquote><div><br></div><div>With Fission (AKA Split Dwarf) you might be able to manage it (check for the BLAH_BLAH_SPLIT_DWARF option in the CMake config)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The big speedup if you’re using BFD ld is to enable shared library support.  This is a particularly big win if you’re doing incremental builds a lot, because the extra startup time overhead is likely to be far less than the 4-5 minutes of extra time spent linking, even on a fast machine.<br></blockquote><div><br></div><div>If you plan to run the regression tests with that build, you'll probably lose the time you gain by linking - the startup of all the llvm tools for all those little tests adds up. A "make check-all" of clang/llvm, at least on my machine (32 core, 32GB of RAM, running of an SSD) is slower (even if you just touch one cc file - causing maximal linking, minimal compiling, etc) with a shared library build, unfortunately.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you do want to do static linking, then your best bet is to do ninja -k 10, which should let it skip over the link jobs that fail, but keep compiling the sources, then ninja -j1, which will make it do the remaining steps one at a time.  In general, the defaults for ninja work well for LLVM/Clang if you have at least one GB of RAM per core.<br></blockquote><div><br></div><div>I think there's a ninja flag for the number of link jobs you want to run in parallel, separate from the usual parallelism.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On a modern laptop, you should be able to do a clean build in 5-10 minutes, but BFD ld can be a bottleneck.  It would be nice if CMake had an option to stick -fuse-ld=gold (or -fuse-ld=lld) in all of the correct places, but when I’ve tried poking the link flags to add this myself I’ve found weird linking errors that I haven’t had time to debug.<br>
<br>
David<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>