[cfe-dev] Building Clang on Windows

[Fábio Picchi via cfe-dev]

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
MSBuild workflow...

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 :)

Fabio


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
>> "C:\PROGRA~2\MICROS~1\2017\PROFES~1\VC\Tools\MSVC\1415~1.267\bin\Hostx86\x86\link.exe
>> /nologo
>> tools\llvm-opt-fuzzer\CMakeFiles\llvm-opt-fuzzer.dir\DummyOptFuzzer.cpp.obj
>> tools\llvm-opt-fuzzer\CMakeFiles\llvm-opt-fuzzer.dir\llvm-opt-fuzzer.cpp.obj
>> tools\llvm-opt-fuzzer\CMakeFiles\llvm-opt-fuzzer.dir\__\__\resources\windows_version_resource.rc.res
>> /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
>> /MANIFEST
>> /MANIFESTFILE:tools\llvm-opt-fuzzer\CMakeFiles\llvm-opt-fuzzer.dir/intermediate.manifest
>> 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...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181016/59a7ccd2/attachment.html>