Repository navigation
build: Allow building ROOT using the Clang shared library #17698
Description
Explain what you would like to see improved and how.
Hello gentle maintainers
My understanding is PR #15563 added support for building Cling as a standalone package using shared libraries from LLVM and Clang. This was facilitated by adopting the new style for embedding LLVM in a project (see https://llvm.org/docs/CMake.html#embedding-llvm-in-your-project).
Similarly, does ROOT's build system allow ROOT to be built using shared libraries from LLVM and Clang? If not, would you be interested in modifying it to support this?
As discussed in that previous PR, there is an advantage to allowing these builds to be done separately, and I assume this modification could be done such that ROOT can still be built with the bundled LLVM and Clang when the builtin options are passed.
For reference, my attempt to build ROOT with external LLVM, Clang and Cling fails at the 'rootcling_stage1' target, which I'm assuming is due to the expectation of building using static libraries (though I'd be happy to be wrong):
ld: /gnu/store/vy8c11s0svpy3hy6g31a704f23cllhj1-cling-1.1/lib/libclingInterpreter.a(LookupHelper.cpp.o):(.text._ZN5clingL18ParseWithShortcutsEPN5clang11DeclContextERNS0_10ASTContextEN4llvm9StringRefEPNS_11InterpreterERNS0_13UnqualifiedIdENS_12LookupHelper11DiagSettingERNS_15ParserStateRAIIE+0x4e5): undefined reference to `clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&, clang::DeclContext*)'
ld: /gnu/store/vy8c11s0svpy3hy6g31a704f23cllhj1-cling-1.1/lib/libclingInterpreter.a(LookupHelper.cpp.o): in function `cling::LookupHelper::findScope(llvm::StringRef, cling::LookupHelper::DiagSetting, clang::Type const**, bool) const':
(.text._ZNK5cling12LookupHelper9findScopeEN4llvm9StringRefENS0_11DiagSettingEPPKN5clang4TypeEb+0x12b9): undefined reference to `clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&, clang::DeclContext*)'
collect2: error: ld returned 1 exit status
make[2]: *** [core/rootcling_stage1/CMakeFiles/rootcling_stage1.dir/build.make:167: core/rootcling_stage1/src/rootcling_stage1] Error 1
That's from building ROOT version 6.32.08 without builtin Cling, LLVM and Clang; LLVM is from tag "ROOT-llvm16-20240621-01" of root-project's fork, Clang is built from that same LLVM, and Cling is version 1.1 built with LLVM from tag "cling-llvm16-20240621-02".
Thanks in advance!
Jake
ROOT version
6.32.08. Also tried with 6.34.02 using Cling 1.2 and LLVM/Clang 18.
Installation method
From source
Operating system
Linux (Guix)
Additional context
No response
Activity
hahnjo commentedon Feb 12, 2025
I think this is related to #17461 where the solution to both issues may be to use
find_package(Clang).hahnjo commentedon Feb 17, 2025
Hi @jakeforster, #17737 fixes #17461. This should get us closer to potentially allow using the Clang shared library, but there are two blockers:
LLVM_LINK_LLVM_DYLIB: Both LLVM androotclingdefines the quite generic-Woption and when linking withlibLLVM.soyou get: CommandLine Error: Option 'W' registered more than once!.libclang-cpp.so(this is the library you mean, right?), we would need to replace all individualclang*dependencies byclang-cpp. From looking atAddClang.cmake, this seems to happen inclang_target_link_librariesbut I'm not sure we have that available in all places we need it...So some progress, but not quite. If you want to give it a try with fresh eyes from your side, please let us know how it goes!
jakeforster commentedon Mar 25, 2025
Hi @hahnjo
Thank you very much for your work toward improving the build system! Sorry I haven't been able to help so far.
I saw in #17737 that you think it might be ready for more testing, so I tried again.
For ROOT's inputs, I used:
I started with ROOT commit 3c0c962 and applied a couple of patches (see master...jakeforster:root:allow-building-against-shared-llvm-library-ctd) to get as far as the
get_target_propertyerrors shown below.Full log: root-build-log.txt.
Thanks! Please let me know if I can try anything out.
hahnjo commentedon Mar 27, 2025
@aaronj0 @vgvassilev looks like CppInterOp made things worse...
guitargeek commentedon Apr 13, 2025
This PR will improve the situation with CppInterOp:
#18386
The problem was that
find_package(Clang)is setting backLLVM_LINK_LLVM_DYLIB=TRUEif LLVM was built with that setting. So we need to set it to false again afterwards.guitargeek commentedon Apr 22, 2025
Hi @hahnjo! FYI, with your revert, I think we went back to the situation where "CppInterOp made things worse" as you said.
hahnjo commentedon Apr 30, 2025
Yes, as expected. I had a quick look and the code that throws the errors is in
interpreter/CppInterOp/lib/Interpreter/CMakeLists.txtwhich has a long section forLLVM_LINK_LLVM_DYLIBdescribed asGet rid of libLLVM-X.so which is appended to the list of static libraries.@aaronj0 can you maybe check that code? It's not clear to me why it is needed because the same file also usesDISABLE_LLVM_LINK_LLVM_DYLIB...vgvassilev commentedon Apr 30, 2025
Because the cmake of shipped llvm are broken. It does not matter if we specify this option, if llvm is shipped in a package manager we have a problem as the cmake config or the cmake targets forces an explicit linking of libLLVM.so.
hahnjo commentedon Apr 30, 2025
DISABLE_LLVM_LINK_LLVM_DYLIBallows overridingLLVM_LINK_LLVM_DYLIB(see also its documentation inllvm_add_library), and so far I have not been presented an example where this didn't work...vgvassilev commentedon Apr 30, 2025
Does not work for shipped llvm on conda. Tracing this down is very hard but I did that once (and forgot most of it) but basically somewhere in the shipped cmake files with the llvm release there is logic which disregards this option and hardcodes libLLVM.so and CppInterOp.so starts loading libLLVM.so and we get the usual assert.
hahnjo commentedon May 6, 2025
btw there is a proposal to default to
LLVM_LINK_LLVM_DYLIB: https://discourse.llvm.org/t/rfc-llvm-link-llvm-dylib-should-default-to-on-on-posix-platforms/85908vgvassilev commentedon May 6, 2025
Added some comment there...