[cling] Anchor the interpreter's clang driver on $ROOTSYS/bin#22754
[cling] Anchor the interpreter's clang driver on $ROOTSYS/bin#22754chrisburr wants to merge 1 commit into
Conversation
On Linux GetExecutablePath() resolves /proc/self/exe, i.e. the path of the
embedding application rather than of ROOT/cling itself. clang's driver derives
its installed directory -- and therefore its GCC-installation and
C-system-header sysroot detection -- from that path. When libCore is embedded
in an executable that does not live next to the ROOT installation (e.g. a user
application built against a relocatable / conda-forge ROOT), the sysroot is
misdetected and the interpreter cannot find the C system headers (assert.h,
time.h, ...) even though they ship with the installation. It surfaces as:
C system headers (glibc/Xcode/Windows SDK) must be installed.
fatal error: 'assert.h' file not found
The resource dir and -I include paths are already made ROOTSYS-relative in
TCling; only the sysroot was still left to clang's /proc/self/exe-based
install-dir guess. Anchor the driver on $ROOTSYS/bin (reusing the LLVMDir /
resource-dir location that is already ROOTSYS-relative) so toolchain and
sysroot detection follow the ROOT installation regardless of where the host
executable lives.
Fixes: conda-forge/root-feedstock#372
| // already made ROOTSYS-relative below. LLVMDir is $ROOTSYS/etc/cling. | ||
| if (LLVMDir) { | ||
| llvm::SmallString<512> rootDriver(LLVMDir); | ||
| llvm::sys::path::append(rootDriver, "..", "..", "bin", "rootcling"); |
There was a problem hiding this comment.
Does this also work with builtin_cling=OFF or builtin_llvm=OFF ?
There was a problem hiding this comment.
Conda-forge is only using external clang/llvm. I had to leave before testing the build but I'll definitely test that case.
There was a problem hiding this comment.
I've confirmed now that this works as expected.
|
Thanks @chrisburr, I started the tests. While experts review, could you perhaps clarify if also the code was created with the help of LLMs (https://github.com/root-project/root/blob/master/CONTRIBUTING.md#ai-assisted-coding-disclosure, https://github.com/root-project/root/pulls?q=is%3Aopen+is%3Apr+label%3A🤖AI-Assisted) |
Test Results 23 files 23 suites 3d 16h 16m 26s ⏱️ For more details on these failures, see this check. Results for commit b639a9fa. |
|
@dpiparo thanks for the reminder, I've updated the PR decription accordingly. |
4 participants
This PR fixes conda-forge/root-feedstock#372. I debugged the issue with the help of LLMs and the final patch was written by an LLM. Normally I would have cleaned up the comment but in this case I think it might be warrented.
🤖 Below is a mostly LLM generated explanation of what the problem is but I think it explains the situation:
On Linux
GetExecutablePath()resolves/proc/self/exe, i.e. the path of the embedding application rather than of ROOT/cling itself.clang's driver derives its installed directory -- and therefore its GCC-installation and C-system-header sysroot detection -- from that path. When libCore is embedded in an executable that does not live next to the ROOT installation (e.g. a user application built against a relocatable / conda-forge ROOT), the sysroot is misdetected and the interpreter cannot find the C system headers (assert.h, time.h, ...) even though they ship with the installation. It surfaces as:
The resource dir and
-Iinclude paths are already made ROOTSYS-relative inTCling; only the sysroot was still left to clang's/proc/self/exe-based install-dir guess. Anchor the driver on $ROOTSYS/bin (reusing theLLVMDir/ resource-dir location that is alreadyROOTSYS-relative) so toolchain and sysroot detection follow the ROOT installation regardless of where the host executable lives.