[cfe-dev] Building Clang on Windows
Fábio Picchi via cfe-dev
cfe-dev at lists.llvm.org
Tue Oct 16 18:56:33 PDT 2018
I am sorry for taking so long to update my status, tough week
I was able to build clang with ninja -j8 on my computer while normally
using it (firefox, unity 3D, visual studio ...). So, I guess MSBuild uses
way too much ran when building in a multithreaded environment? Should I try
to debug MSBuild or file a bug report?
Anyway, I watched as the other thread on whether or not to abandon the
What if cmake generated by default a solution that builds using only a
single thread? This way people would not complain when trying to use this
workflow and mantainers / more experienced users would change this setting
when they find it appropriate.
Thank you very much for the support so far! Very nice community, I hope to
contribute soon :)
On Sun, Oct 7, 2018 at 9:04 PM Zachary Turner <zturner at google.com> wrote:
> Actually, scratch that. This is with the x86 host toolchain. :(
> On Sun, Oct 7, 2018 at 5:01 PM Zachary Turner <zturner at google.com> wrote:
>> Well, I am actually getting this now even with ninja.
>> FINAL LINK: command
>> /out:bin\llvm-opt-fuzzer.exe /implib:lib\llvm-opt-fuzzer.lib
>> /pdb:bin\llvm-opt-fuzzer.pdb /version:0.0 /machine:X86 /STACK:10000000
>> /debug /INCREMENTAL /subsystem:console lib\LLVMX86CodeGen.lib
>> lib\LLVMX86AsmParser.lib lib\LLVMX86AsmPrinter.lib lib\LLVMX86Desc.lib
>> lib\LLVMX86Disassembler.lib lib\LLVMX86Info.lib lib\LLVMX86Utils.lib
>> lib\LLVMAnalysis.lib lib\LLVMBitReader.lib lib\LLVMBitWriter.lib
>> lib\LLVMCodeGen.lib lib\LLVMCore.lib lib\LLVMCoroutines.lib lib\LLVMipo.lib
>> lib\LLVMIRReader.lib lib\LLVMAggressiveInstCombine.lib
>> lib\LLVMInstCombine.lib lib\LLVMInstrumentation.lib lib\LLVMFuzzMutate.lib
>> lib\LLVMMC.lib lib\LLVMObjCARCOpts.lib lib\LLVMScalarOpts.lib
>> lib\LLVMSupport.lib lib\LLVMTarget.lib lib\LLVMTransformUtils.lib
>> lib\LLVMVectorize.lib lib\LLVMPasses.lib lib\LLVMAsmPrinter.lib
>> lib\LLVMGlobalISel.lib lib\LLVMSelectionDAG.lib lib\LLVMX86AsmPrinter.lib
>> lib\LLVMX86Utils.lib lib\LLVMMCDisassembler.lib lib\LLVMCodeGen.lib
>> lib\LLVMipo.lib lib\LLVMBitWriter.lib lib\LLVMIRReader.lib
>> lib\LLVMAsmParser.lib lib\LLVMLinker.lib lib\LLVMInstrumentation.lib
>> lib\LLVMScalarOpts.lib lib\LLVMAggressiveInstCombine.lib
>> lib\LLVMInstCombine.lib lib\LLVMTarget.lib lib\LLVMVectorize.lib
>> lib\LLVMTransformUtils.lib lib\LLVMAnalysis.lib lib\LLVMObject.lib
>> lib\LLVMBitReader.lib lib\LLVMMCParser.lib lib\LLVMMC.lib
>> lib\LLVMDebugInfoCodeView.lib lib\LLVMDebugInfoMSF.lib
>> lib\LLVMProfileData.lib lib\LLVMCore.lib lib\LLVMBinaryFormat.lib
>> lib\LLVMSupport.lib psapi.lib shell32.lib ole32.lib uuid.lib advapi32.lib
>> delayimp.lib -delayload:shell32.dll -delayload:ole32.dll
>> lib\LLVMDemangle.lib kernel32.lib user32.lib gdi32.lib winspool.lib
>> shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
>> tools\llvm-opt-fuzzer\CMakeFiles\llvm-opt-fuzzer.dir/manifest.res" failed
>> (exit code 1102) with the following output:
>> LINK : fatal error LNK1102: out of memory
>> I'll dig in some.
>> On Sun, Oct 7, 2018 at 4:42 PM Zachary Turner <zturner at google.com> wrote:
>>> On Sun, Oct 7, 2018 at 4:30 PM Fábio Picchi via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>> > The problem is that by default VS2017 builds Clang in parallel to how
>>>> many cores you have
>>>> That would explain my problem in building clang then as I have an eight
>>>> core Ryzen 7 1700X with only 8GB of RAM. I will try to build with parallel
>>>> building off...
>>>> But did ninja ignore these build options? Because I was able to build
>>>> clang using it without any problem.
>>>> I will look into it and post some results tomorrow.
>>> Ninja is not MSBuild, it has its own algorithm for scheduling parallel
>>> jobs (you can control this with the -j option, but by default it picks
>>> something sane). You can see what happens if you pass -j 8.
>>> I still don't see how your situation would result in an out of memory
>>> error. How much physical memory your system has is totally irrelevant, you
>>> still cannot "run out of memory" from the process's point of view unless
>>> you also run out of disk space for swap, which is extremely unlikely unless
>>> you have configured a very small swap.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev