Hi,
The time required to build ROOT v6 (actually v6-02-00-patches branch) with cmake seems to be
mostly due to building the LLVM modules, so I thought why not just install LLVM (on Ubuntu 14.10,
which gives v3.5.0) and then do
$ cmake -Dbuiltin_llvm=OFF
?
Unfortunately, even after having hacked the LLVM cmake modules which are not up to scratch
(see bugs.launchpad.net/ubuntu/+sour … ug/1387011), this does not seem to be
possible as, even though the builtin_llvm support has been disabled:
it looks like the build system still wants to set up the build for the built-in LLVM modules:
– Constructing LLVMBuild project information
CMake Error at interpreter/llvm/src/cmake/modules/AddLLVM.cmake:312 (add_library):
add_library cannot create target “LLVMSupport” because an imported target
with the same name already exists.
Call Stack (most recent call first):
interpreter/llvm/src/cmake/modules/AddLLVM.cmake:404 (llvm_add_library)
interpreter/llvm/src/lib/Support/CMakeLists.txt:30 (add_llvm_library)
CMake Error at interpreter/llvm/src/cmake/modules/AddLLVM.cmake:376 (target_link_libraries):
Cannot specify link libraries for target “LLVMSupport” which is not built
by this project.
Call Stack (most recent call first):
interpreter/llvm/src/cmake/modules/AddLLVM.cmake:404 (llvm_add_library)
interpreter/llvm/src/lib/Support/CMakeLists.txt:30 (add_llvm_library)
[quote]it looks like the build system still wants to set up the build for the built-in LLVM modules:[/quote]the built-in llvm and clang are currently required and are different from any other llvm/clang you might get somewhere else. They have been tweaked with several patches that make cling (and ROOT) possible and are not yet ready (some solely for lack of time to properly clean them up and test and package) to be pushed upstream.
@pcanal do you have any news regarding this subject? Is it true that all ROOT-related tweaks to LLVM were pushed upstream? If so, do you know which version of LLVM would support them?
Yes, you need LLVM 5.0.x to use with ROOT. However, there are corner cases where ROOT won’t work, even if it builds successfully, so be aware. Just add -Dbuiltin_llvm=OFF -DLLVM_CONFIG=/path/to/llvm-config and you should be able to build with external LLVM.
if I hit one of them will I get a complete failure like something won’t compile, an exception would be thrown or will I get silently some garbage result?
is the reason for these corner cases that not all tweaks were passed to LLVM 5.0?
I have access to LLVM 6.0-1 for Debian Stretch (backports) - does it make a difference?
As I said, you need LLVM 5.0.x. For corner cases, you’ll see a crash with ROOT with std::terminate being called due to double initialization of some globals. It’s related to the fact that we dlopenlibCore.so instead of linking it, and sometimes there is double initialization.
I see that there is now also an option builtin_clang. Can I disable builtin_clang having LLVM 5.0 and libclang-5.0? Or there are more problems ahead than for LLVM only?
Only LLVM can be external without patches. You can build against external Clang, but you have to apply the same patches that are applied to the builtin version, or it won’t work, so I think in that case you might as well just build the included Clang. Cheers,
Thank you for the info. In this situation indeed it only makes sense to build the included Clang. Are there plans to push these patches upstream? I couldn’t check how much faster is the build of ROOT without builtin_clang, but system LLVM makes it 25-33% faster on the machine where I made the test.
Why don’t you just link with libCore instead of dlopen, apart from historical reasons, if it can cause troubles with double intitialization - are there use cases when libCore is not loaded?
Are there plans to push patches to clang upstream, so that in the future we can build ROOT with llvm and clang provided by the system?
Linking to libCore depends on libCling and the same time libCling depends on libCore. Even if we break the cyclic dependency we have a few more problems to solve. One of which is that the llvm symbols in libCling should not leak from the outside because this would preclude third-party software (in particular experiments software stacks) to have their own version of llvm. In is true that we might get around the problem by using hidden visibility. What is the exact problem you try to solve?
On the clang patches. LLVM is patch free and you can link against vanilla llvm-5.0. We have around 70-80 patches in clang. Most of them can be put upstream or are trivial to reimplement and it should not be a lot of work. However, we have two major patches which require a lot of work. One is the strong-typedef-like feature aka Double32_t. The second one is removing eager deserializations of template specialization (https://reviews.llvm.org/D41416). Both have a way forward but require time. We have a couple more non-trivial patches but not as laborious.
In essence, we are sloooowly getting there. A year ago there was not even buildin_llvm=Off and builtin_clang=Off.
The problem that I am trying to solve is not a major one, it is just an inconvenience - at least building LLVM internally took about 1/3 of the whole build time for ROOT. I don’t know about CLANG. Ideally I would like to prevent ROOT from building things that are already present in the system (provided that the things are rather stable libraries, not to run into a problem that new ROOT pro depends on something that will enter my system only with the next release in the next 2 years). This is why I am trying to understand what is the situation with the heaviest dependencies and what I can expect in the future. Since this is merely an inconvenience and not a showstopper of any kind, I am not even trying to ask for faster pace with this. I am very glad that now LLVM is relatively safe to use. I am also happy to know that you intend on pushing clang upstream in some non-well defined future.
Realistically, ROOT will always depend on a specific version of llvm and clang. Say, llvm-5.0/clang-5.0, and we cannot even provide a guarantee if llvm-5.0.1 update will not break it. Neither llvm nor clang guarantee API (not to speak ABI) stability (and for a good reason).
Not to speak that some of the distros do not have static libraries in the distributions of llvm but *.so file. With the current design of the system that will not work.
ROOT is already taking a major step to for it’s major upgrades. We are upgrading only to stable and well-tested releases (in the past we would just pick up a pseudo random commit number).