This is required for GCC which uses libcalls for outlined atomics. Reviewed by: dim Differential Revision: https://reviews.freebsd.org/D55157
In commit 2e47f35be5dc libllvm, libclang and liblldb were converted into private shared libraries. This allowed clang, lld, lldb, and other llvm tools to be linked against these shared libraries, which makes them smaller and avoids duplication. However, this also comes at the cost of some performance, since the dynamic libraries are quite large, and contain lots of long symbols (mangled C++ identifiers). Add a WITH_LLVM_LINK_STATIC_LIBRARIES build knob that can be used to go back to the previous behavior: libllvm, libclang and liblldb are built as internal static libraries, i.e. only available during buildworld, and fully linked into the various executables such as clang, lld, etc. PR: 287447 Reviewed by: emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D50956
Fixes: cf1eaaf41cef MFC after: 1 week
In commit 2e47f35be5dc libllvm, libclang and liblldb were converted into private shared libraries. This allowed clang, lld, lldb, and other llvm tools to be linked against these shared libraries, which makes them smaller and avoids duplication. However, upstream builds the shared libraries using several visibility options, which reduces the number of external symbols, and makes the libraries a bit smaller. On my test machine: * libprivatellvm.so goes from 75643 to 34706 symbols (~54% reduction) * libprivateclang.so goes from 53250 to 33531 symbols (~37% reduction) * libprivatelldb.so goes from 27242 to 18798 symbols (~31% reduction) Note: to get the full benefit, a clean build is required. Incremental builds should still work, but I didn't want to force a full rebuild on everybody. MFC after: 1 week
In 986e05bc2a18 I revamped the build for all the llvm subprojects. Among others I added objects under contrib/llvm-project/llvm/lib/TableGen, but I missed that upstream explicitly removes these when building the shared llvm library: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.7/llvm/tools/llvm-shlib/CMakeLists.txt#L23 In 2e47f35be5dc I converted libllvm to a shared library. From that point onwards, some of the global command line option objects registered in llvm/lib/TableGen/Main.cpp conflict with similar objects in tools like llvm-cov, llvm-as, etc. This results in an error when running these tools: "CommandLine Error: Option 'o' registered more than once!", followed by a fatal exit. Fix this by removing the TableGen objects from libllvm. Note that we no longer install any of the tblgen binaries, these are only used during buildworld, and then in a statically linked form. PR: 291233 MFC after: 3 days
This allows clang, lld, lldb, and other llvm tools to be linked against these shared libraries, which makes them smaller and avoids duplication. Since these are not quite the same as the shared libraries shipped by the upstream llvm build system, and we do not want to expose the ABI to external programs such as ports, make them private libraries. Note that during the cross-tools stage they are still built as static libraries, so the cross compiler and linker are static binaries, as they have always been. This also requires a depend-cleanup.sh kludge which will be added in a follow-up commit, to ensure binaries are rebuilt against the shared libraries in case of incremental builds. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D49967
This is not harmful when making a static library apparently, but will result in duplicate symbol errors when making a dynamic library. MFC after: 3 days
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2. PR: 280562 MFC after: 1 month
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-19-init-18630-gf2ccf80136a0, the last commit before the upstream release/19.x branch was created. PR: 280562 MFC after: 1 month
Sponsored by: Juniper Networks, Inc.