brechtsanders
Some ways to make LLVM builds smaller
When I opened #56, I didn' relaize how big it would get. There are a bunch of ways to make it smaller though. First, my C:\mingw64\libs directory is 871 MB, most of which are static libs that are a part of LLVM libclangDriver.a, libLLVMSupport.a ETC. There are also 30 + MB of LLVM's headers in the include directory. , but I don't think people will want to use these they probably prefer to compile LLVM along with their project, so deleting them would be a way to save a lot of space. A possible way to do that is to use the install-distribution instead of the install target, see Building a distribution. It notes that the install target installs everything, probably including the LLVM static libs and headers. Next, https://github.com/mstorsjo/llvm-mingw/issues/192 has a table indicating that building Clang with its self instead of GCC produces binaries that are roughly 10% smaller and faster, and might also improve build times though you might have to use LLD. Another trick employed by LVM-MinGW is to have only one clang, LLD executable ETC and create little wrapper programs called clang, clang++ that just invoke clang with the arguments they were called with. Looking at mt LLVM distribution, there are four clang-based executables (clang, clang++, clang-cl, and clang-cpp) that are 117 MB each while LLVM-MinGW only has one. Another way to reduce LLVM size is via the -DLLVM_TARGETS_TO_BUILD CMake option. This option controls which targets LLVM / Clang can generate code for, such as PowerPC or WASM. Since we're on Windows though, and there is no good way to cross-compile with LLVM, we can probably get away with -DLLVM_TARGETS_TO_BUILD=host, which allows generating code for only the host platform (x86/64). Since you've seemingly included AVR target support in GCC, you probably also want it in LLVM, but you need to use -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD.
I don't think to point out the maintainer what to do is the right way.
Though, I can't speak for Brecht, feature request and bug reports will be encouraged, but changing the distribution is a strange thing to ask.
People download and use the current distribution and no one complained so far about the way it's created. I use the distribution to compile my own with shared libs or not.
Personally, I'd like to have in the distro some additional libraries precompiled, like libffi, zlib, lzma, z3 solver, libxml2 and some changes, like usage of UCRT instead of MSVCRT, but your request is even strager.
This was supposed to be a bunch of suggestions, sorry if it didn't come out that way. The reason this is a problem is because using LLVM_BUILD_SHARED_LIBS is not recommended in the LLVM documentation and sometimes causes weird things to happen, and building LLVM statically is literally 4.9 GB including MinGW once you uncompress it, a full GB of which is static libraries containing LLVM source code. It seems like something worth fixing to me.
Can you share your clang distribution, here, on github?
LLVM_LINK_LLVM_DYLIB worked in 12.0.0 version; when I compiled 12.0.1 with LLVM_ENABLE_EH=On and LLVM_ENABLE_RTTI=On it produced weird bugs. when I turned LLVM_LINK_LLVM_DYLIB off it compiled and worked perfectly.
The build I just released (with LLVM 12.0.1) was build with:
cmake -Wno-dev -GNinja -DCMAKE_BUILD_TYPE:STRING=MinSizeRel -DBUILD_SHARED_LIBS:BOOL=ON -DLLVM_BUILD_STATIC=OFF -DLIBCLANG_BUILD_STATIC:BOOL=OFF -DLLVM_LINK_LLVM_DYLIB:BOOL=OFF -DDCLANG_LINK_CLANG_DYLIB:BOOL=ON -DLLVM_HOST_TRIPLE:STRING=$RUNPLATFORM -DLLVM_TARGETS_TO_BUILD:STRING="X86;NVPTX;AMDGPU;ARM;AArch64" -DLLVM_ENABLE_PROJECTS:STRING="clang;clang-tools-extra;compiler-rt;lld;lldb;libclc" -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS:BOOL=OFF -DLLVM_ENABLE_THREADS:BOOL=ON -DCLANG_BUILD_TOOLS:BOOL=ON -DCLANG_DEFAULT_RTLIB:STRING=libgcc -DCLANG_DEFAULT_CXX_STDLIB:STRING=libstdc++ -DCLANG_DEFAULT_OPENMP_RUNTIME:STRING=libgomp -DCLANG_DEFAULT_UNWINDLIB:STRING=libgcc -DCLANG_ENABLE_PROTO_FUZZER:BOOL=OFF -DCLANG_ENABLE_STATIC_ANALYZER:BOOL=ON -DLLDB_ENABLE_LIBXML2:STRING=ON -DLLDB_ENABLE_LUA:STRING=ON -DLLDB_ENABLE_LZMA:STRING=ON -DLLVM_ENABLE_EH:BOOL=$(if ( echo $RUNPLATFORM | grep -q x86_64 ); then echo "ON"; else echo "OFF"; fi) -DLLVM_ENABLE_RTTI:BOOL=ON -DLLVM_ENABLE_MODULES:BOOL=OFF -DLLVM_ENABLE_ASSERTIONS:BOOL=OFF -DLLVM_ENABLE_FFI:BOOL=ON -DLLVM_OPTIMIZED_TABLEGEN:BOOL=ON -DLLVM_ENABLE_LIBXML2:STRING=ON -DLLVM_ENABLE_THREADS:BOOL=ON -DLLVM_ENABLE_UNWIND_TABLES:BOOL=ON -DLLVM_ENABLE_Z3_SOLVER:BOOL=ON -DLLVM_INCLUDE_TOOLS:BOOL=ON -DLLVM_INCLUDE_UTILS:BOOL=ON -DLLVM_INSTALL_UTILS:BOOL=ON -DLLVM_ENABLE_LIBEDIT:BOOL=OFF -DLLDB_ENABLE_LIBEDIT:STRING=OFF -DLLDB_ENABLE_CURSES:BOOL=OFF -DLLDB_ENABLE_LIBXML2:BOOL=ON -DLLDB_ENABLE_LUA:BOOL=ON -DLLDB_ENABLE_LZMA:BOOL=ON -DLLDB_ENABLE_PYTHON:BOOL=OFF -DPython3_EXECUTABLE:PATH=$PYDIR/python.exe -DLLVM_INCLUDE_DOCS:BOOL=OFF -DCLANG_INCLUDE_TESTS:BOOL=OFF -DCOMPILER_RT_INCLUDE_TESTS:BOOL=OFF -DLLDB_INCLUDE_TESTS:BOOL=OFF -DLLVM_INCLUDE_GO_TESTS:BOOL=OFF -DLLVM_INCLUDE_TESTS:BOOL=OFF -DLLVM_TOOL_LLVM_C_TEST_BUILD:BOOL=OFF -DLLVM_INCLUDE_EXAMPLES:BOOL=OFF -DLLVM_BUILD_BENCHMARKS:BOOL=OFF -DLLVM_BUILD_TESTS:BOOL=OFF -DBUILD_CLANG_FORMAT_VS_PLUGIN:BOOL=OFF -DCLANG_PLUGIN_SUPPORT:BOOL=ON -DCLANG_ENABLE_CLANGD:BOOL=ON -DCLANG_TOOL_APINOTES_TEST_BUILD:BOOL=OFF -DCLANG_TOOL_ARCMT_TEST_BUILD:BOOL=OFF -DCLANG_TOOL_CLANG_IMPORT_TEST_BUILD:BOOL=OFF -DCLANG_TOOL_C_ARCMT_TEST_BUILD:BOOL=OFF -DCLANG_TOOL_C_INDEX_TEST_BUILD:BOOL=OFF -DCLANG_INCLUDE_DOCS:BOOL=OFF -DCLANG_BUILD_EXAMPLES:BOOL=OFF -DLLD_BUILD_TOOLS:BOOL=ON -DLLDB_TOOL_LLDB_SERVER_BUILD:BOOL=OFF -DLLDB_TOOL_LLDB_VSCODE_BUILD:BOOL=OFF -DLLDB_DISABLE_PYTHON:BOOL=ON -Sllvm -Bbuild_shared
ninja -Cbuild_shared install/strip
Haven't tried yet, but I think that should be possible. It would need to be completely seperate from the rest though, and I'm not sure if this is to be considered a cross-compiler.
@brechtsanders I've found a good set of starting CMake options that can be used to build LLVM and is also much smaller than your enormous mess of a build command. Half of the options you're setting are already the default.
cmake -Wno-dev -G Ninja -DCMAKE_BUILD_TYPE=release -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;compiler-rt;lld;lldb;libclc" -DCLANG_DEFAULT_RTLIB=libgcc -DCLANG_DEFAULT_OPENMP_RUNTIME=libgomp -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;ARM;AArch64" -DCLANG_DEFAULT_CXX_STDLIB=libstdc++ -DCLANG_DEFAULT_UNWINDLIB=libgcc -DCLANG_ENABLE_STATIC_ANALYZER:BOOL=ON -DLLVM_ENABLE_RTTI:BOOL=ON -DLLVM_ENABLE_FFI=ON -DLLVM_ENABLE_LIBXML2:STRING=ON -DLLVM_ENABLE_Z3_SOLVER:BOOL=ON -DLLVM_INSTALL_TOOLCHAIN_ONLY=on ../llvm The resulting folder containing both LLVM and MinGW64 is 1.02 GB It turns out that -DLLVM_BUILD_LLVM_DYLIB doesn't work. Same problem as BUILD_SHARED_LIBS, I.E. Each time LLD is run, it has a chance to never finish.
Do you have the lld hanging issue also with my latest build of LLVM 12.0.1?
Yeah, just checked now and it got stuck three times.
On 7/29/21, Brecht Sanders @.***> wrote:
Do you have the
lldhanging issue also with my latest build of LLVM 12.0.1?-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/brechtsanders/winlibs_mingw/issues/68#issuecomment-889354602
I have spent the last few days building a winlibs.com GCC/MinGW-w64 build against UCRT runtime. https://github.com/brechtsanders/winlibs_mingw/releases/tag/11.2.0-9.0.0-ucrt-r1
This was one of the suggestions you mentioned earlier in this issue.
I don't know if this would work, but LLVM-MinGW uses LLVM_LINK_LLVM_DYLIB now and it appears to be stable. If it works for you, it'll reduce the number of DLLs in the distribution by maybe an order of m mentions in its documentation that it should only be used for testing, not release builds.agnitude and possibly fix some crashes because LLVM_BUILD_SHARED_LIBS
@brechtsanders, might I ask if your distribution using LLVM_BUILD_LLVM_DYLIB now and llvm-ml to compile openmp?