Hi, I am seeing an LLVM build failure with recent LLD on x86 like: [...] lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMScalarOpts.a lib/libLLVMAgg ressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTransformUtils.a lib/libLLVMDebugInfoDWARF.a lib/lib LLVMMCDisassembler.a lib/libLLVMExecutionEngine.a lib/libLLVMTarget.a lib/libLLVMAnalysis.a lib/libLLVMProfil eData.a lib/libLLVMRuntimeDyld.a lib/libLLVMObject.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugI nfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMRemarks.a lib/li bLLVMBitstreamReader.a lib/libLLVMTextAPI.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a /usr/lib64/libz.so -lrt -ldl -ltinfo -lpthread -lm lib/libLLVMDemangle.a && : LLVM ERROR: out of memory Stack dump: 0. Program arguments: /home/usr4/c74014i/opt/clang/stable/bin/ld.lld @/tmp/response-5051e9.txt LLVM ERROR: out of memory clang-11: error: unable to execute command: Aborted clang-11: error: linker command failed due to signal (use -v to see invocation) [32/492] Building CXX object tools/llvm-cov/CMakeFiles/llvm-cov.dir/gcov.cpp.o As reported on Discord, switching back to ld works around this issue. On my system a process gets a 6 GB of memory max can be used, and I use ninja -j16. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/dcc39115/attachment.html>
I take it back it is -j8. On Mon, Feb 3, 2020 at 8:01 AM Itaru Kitayama <itaru.kitayama at gmail.com> wrote:> Hi, > I am seeing an LLVM build failure with recent LLD on x86 like: > > [...] > lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMScalarOpts.a > lib/libLLVMAgg > ressiveInstCombine.a lib/libLLVMInstCombine.a > lib/libLLVMTransformUtils.a lib/libLLVMDebugInfoDWARF.a lib/lib > LLVMMCDisassembler.a lib/libLLVMExecutionEngine.a lib/libLLVMTarget.a > lib/libLLVMAnalysis.a lib/libLLVMProfil > eData.a lib/libLLVMRuntimeDyld.a lib/libLLVMObject.a > lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugI > nfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMBitReader.a > lib/libLLVMCore.a lib/libLLVMRemarks.a lib/li > bLLVMBitstreamReader.a lib/libLLVMTextAPI.a lib/libLLVMBinaryFormat.a > lib/libLLVMSupport.a /usr/lib64/libz.so > -lrt -ldl -ltinfo -lpthread -lm lib/libLLVMDemangle.a && : > LLVM ERROR: out of memory > Stack dump: > 0. Program arguments: /home/usr4/c74014i/opt/clang/stable/bin/ld.lld > @/tmp/response-5051e9.txt > LLVM ERROR: out of memory > clang-11: error: unable to execute command: Aborted > clang-11: error: linker command failed due to signal (use -v to see > invocation) > [32/492] Building CXX object > tools/llvm-cov/CMakeFiles/llvm-cov.dir/gcov.cpp.o > > As reported on Discord, switching back to ld works around this issue. > On my system a process gets a 6 GB of memory max can be used, and I use > ninja -j16. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/04e9be95/attachment.html>
See here you can specify the number of concurrent link jobs https://llvm.org/docs/CMake.html#llvm-specific-variables with LLVM_PARALLEL_LINK_JOBS. Increasing swap space is also an option, and I have had to do this on a system with only 8gb of memory. As to why it work with ld.gold/bfd and not lld I couldn't say, this seems contrary to what most people report which is that lld uses less memory and is faster. Usually this list recommends lld, so I'm surprised. Also BUILD_SHARED_LIBS should be helpful. On Sun, Feb 2, 2020 at 6:01 PM Itaru Kitayama via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hi, > I am seeing an LLVM build failure with recent LLD on x86 like: > > [...] > lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMScalarOpts.a lib/libLLVMAgg > ressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTransformUtils.a lib/libLLVMDebugInfoDWARF.a lib/lib > LLVMMCDisassembler.a lib/libLLVMExecutionEngine.a lib/libLLVMTarget.a lib/libLLVMAnalysis.a lib/libLLVMProfil > eData.a lib/libLLVMRuntimeDyld.a lib/libLLVMObject.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugI > nfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMRemarks.a lib/li > bLLVMBitstreamReader.a lib/libLLVMTextAPI.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a /usr/lib64/libz.so > -lrt -ldl -ltinfo -lpthread -lm lib/libLLVMDemangle.a && : > LLVM ERROR: out of memory > Stack dump: > 0. Program arguments: /home/usr4/c74014i/opt/clang/stable/bin/ld.lld @/tmp/response-5051e9.txt > LLVM ERROR: out of memory > clang-11: error: unable to execute command: Aborted > clang-11: error: linker command failed due to signal (use -v to see invocation) > [32/492] Building CXX object tools/llvm-cov/CMakeFiles/llvm-cov.dir/gcov.cpp.o > > As reported on Discord, switching back to ld works around this issue. > On my system a process gets a 6 GB of memory max can be used, and I use > ninja -j16. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Alex et al., For me, setting explicitly LLVM_PARALLEL_LINK_JOBS to 2 did not help, but BUILD_SHARED_LIBS=ON did the trick! Thanks! On Mon, Feb 3, 2020 at 8:16 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote:> See here you can specify the number of concurrent link jobs > https://llvm.org/docs/CMake.html#llvm-specific-variables with > LLVM_PARALLEL_LINK_JOBS. Increasing swap space is also an option, and > I have had to do this on a system with only 8gb of memory. As to why > it work with ld.gold/bfd and not lld I couldn't say, this seems > contrary to what most people report which is that lld uses less memory > and is faster. Usually this list recommends lld, so I'm surprised. > Also BUILD_SHARED_LIBS should be helpful. > > On Sun, Feb 2, 2020 at 6:01 PM Itaru Kitayama via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > I am seeing an LLVM build failure with recent LLD on x86 like: > > > > [...] > > lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a > lib/libLLVMScalarOpts.a lib/libLLVMAgg > > ressiveInstCombine.a lib/libLLVMInstCombine.a > lib/libLLVMTransformUtils.a lib/libLLVMDebugInfoDWARF.a lib/lib > > LLVMMCDisassembler.a lib/libLLVMExecutionEngine.a lib/libLLVMTarget.a > lib/libLLVMAnalysis.a lib/libLLVMProfil > > eData.a lib/libLLVMRuntimeDyld.a lib/libLLVMObject.a > lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugI > > nfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMBitReader.a > lib/libLLVMCore.a lib/libLLVMRemarks.a lib/li > > bLLVMBitstreamReader.a lib/libLLVMTextAPI.a lib/libLLVMBinaryFormat.a > lib/libLLVMSupport.a /usr/lib64/libz.so > > -lrt -ldl -ltinfo -lpthread -lm lib/libLLVMDemangle.a && : > > LLVM ERROR: out of memory > > Stack dump: > > 0. Program arguments: > /home/usr4/c74014i/opt/clang/stable/bin/ld.lld @/tmp/response-5051e9.txt > > LLVM ERROR: out of memory > > clang-11: error: unable to execute command: Aborted > > clang-11: error: linker command failed due to signal (use -v to see > invocation) > > [32/492] Building CXX object > tools/llvm-cov/CMakeFiles/llvm-cov.dir/gcov.cpp.o > > > > As reported on Discord, switching back to ld works around this issue. > > On my system a process gets a 6 GB of memory max can be used, and I use > > ninja -j16. > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/22370da6/attachment.html>