using the bat script build_llvm_package.bat on windows

where should the file build_llvm_package.bat be placed and how should the build_llvm_package.bat be called?
or
is there a another way to do a two stage build of the llvm project on windows starting with using visual studio 2017 community.

build_llvm_package.bat is only a template for building releases.

You can use it as reference, but for a two-stage build the simplest you can do is:

after following the instructions for ninja check-all:

FAILED: bin/libclang.dll lib/liblibclang.dll.a
cmd.exe /C “cd . && C:\Strawberry\c\bin\c++.exe -Wa,-mbig-obj -Werror=date-time
-Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-fi
eld-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-unin
itialized -Wno-class-memaccess -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno
-comment -fno-common -Woverloaded-virtual -fno-strict-aliasing -O2 C:/temp/llv
m-build/llvm-project/build1/tools/clang/tools/libclang/libclang.def -shared -o b
in\libclang.dll -Wl,–out-implib,lib\liblibclang.dll.a -Wl,–major-image-version
,11,–minor-image-version,0 @CMakeFiles\libclang.rsp && cd .”
C:/Strawberry/c/bin/…/lib/gcc/x86_64-w64-mingw32/8.3.0/…/…/…/…/x86_64-w64-m
ingw32/bin/ld.exe: cannot find lib/libLLVMCore.a: Too many open files
C:/Strawberry/c/bin/…/lib/gcc/x86_64-w64-mingw32/8.3.0/…/…/…/…/x86_64-w64-m
ingw32/bin/ld.exe: cannot find lib/libLLVMRemarks.a: Too many open files
C:/Strawberry/c/bin/…/lib/gcc/x86_64-w64-mingw32/8.3.0/…/…/…/…/x86_64-w64-m
ingw32/bin/ld.exe: cannot find lib/libLLVMBitstreamReader.a: Too many open files

This is like EMFILE on linux. If it’s transient, you can nudge the file limit up or nudge concurrency down. On linux the open file count is specified in ulimit and sysctl, not sure about Windows. Nudging concurrency down is something most folks have to do during linking anyways, for memory’s sake. If you haven’t already, try setting DLLVM_PARALLEL_LINK_JOBS (per https://llvm.org/docs/GettingStarted.html#common-problems ).

Another potential cause is some kind of stall/system locking, you can try to identify whether there’s some critical resource that’s causing jobs to pile up.

If you don’t have a lot of confidence in the host toolchain, maybe it’s a file descriptor leak.

You have Strawberry Perl installed, and that comes with MinGW. cmake picks up the GNU binutils inside that distribution, instead of MSVC cl.exe. Like Brian suggested, there are too many link jobs going on, so you could re-run ninja check-all -j 2, but that will be slower to build.

If you want to build the first stage with MSVC, do this (because cmake doesn’t like backslashes):

D:\llvm-project> set VS2017=%VCToolsInstallDir:=/%

And the re-run cmake, telling it explicitly which compiler it should use (similar to what you’ll do for the second stage):

D:\llvm-project\build1> cmake -GNinja …/llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_OPTIMIZED_TABLEGEN=ON -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_PROJECTS=“llvm;clang;lld” -DCMAKE_C_COMPILER="%VS2017%/bin/HostX64/x64/cl.EXE" -DCMAKE_CXX_COMPILER="%VS2017%/bin/HostX64/x64/cl.EXE" -DCMAKE_LINKER="%VS2017%/bin/HostX64/x64/link.EXE"

Envoyé : April 12, 2020 6:59 PM