[llvm-dev] difference with autotools, cmake and ninja building methods
Justin Bogner via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 1 09:26:22 PST 2015
David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes:
> On 1 Dec 2015, at 10:03, 慕冬亮 via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> collect2: fatal error: ld terminated with signal 9 [Killed]
>> compilation terminated.
>> [2706/2983] Linking CXX executable bin/clang-check
>> ninja: build stopped: subcommand failed.
> 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.
> 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.
> 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.
There's a cmake parameter `-DLLVM_PARALLEL_LINK_JOBS=1` that will limit
the number of concurrent link jobs. That makes for a better experience
than running ninja twice :)
> 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
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev