Change:
endif() get_target_property(lldb_python_bindings_dir swig_wrapper_python BINARY_DIR) finish_swig_python("lldb-python" "${lldb_python_bindings_dir}" "${lldb_python_target_dir}") <ins> diff --git a/source/API/CMakeLists.txt b/source/API/CMakeLists.txt index b5633e2..86e4738 100644 --- a/source/API/CMakeLists.txt	2024-05-30 21:38:39.829955586 -0700 +++ b/source/API/CMakeLists.txt	2024-05-30 21:38:48.015673758 -0700 @@ -112,14 +112,6 @@ ${option_install_prefix} ) -# lib/pythonX.Y/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so, -# which depends on lib/libLLVM*.so (BUILD_SHARED_LIBS) or lib/libLLVM-10git.so -# (LLVM_LINK_LLVM_DYLIB). Add an additional rpath $ORIGIN/../../../../lib so -# that _lldb.so can be loaded from Python. -if(LLDB_ENABLE_PYTHON AND (BUILD_SHARED_LIBS OR LLVM_LINK_LLVM_DYLIB) AND UNIX AND NOT APPLE) -  set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH "$ORIGIN/../../../../lib${LLVM_LIBDIR_SUFFIX}") -endif() - if(Python3_RPATH) set_property(TARGET liblldb APPEND PROPERTY INSTALL_RPATH "${Python3_RPATH}") set_property(TARGET liblldb APPEND PROPERTY BUILD_RPATH   "${Python3_RPATH}") </ins>

Discussion:
I expect that these dependencies should resolve to /nix/store/ and not to /usr/lib/. FWIW, I am working on adding LLVM 18 support to bpftrace CI. (We are loving nix's role in our CI, btw). I'm not sure if enough information is contained in the store path I shared above. But if not, I have a reproducer here: . Just run . You should see the following failure: I discovered lldb is related through LDDEBUG=all: dynamic dependencies to resolve into nix store. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --(apologies if I got the list wrong) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
paths look ok on ubuntu.
I tried building on my other arch computer and I get the same failure. However, on my fedora 39 machine, it succeeds. But perhaps more concerning is that our github actions built binaries are failing too: The workflow that builds it is here: I think default GHA runners use ubuntu, so that is very odd.
Not reproducible on latest commit with aarch64-linux & x86_64-linux.
Debugged a little further. Seems like RPATH is not correctly set: Note how is the second entry. This is probably what's triggering the resolution into the host.
Looking at the log (via ), I see this cmake log: So cmake is setting $ORIGIN
I do see that on aarch64-linux but things resolve right.
, perhaps your host system has the correct version of the dependency installed? I found the string in cmake source: Trying to find lldb cmake sources now
I'm on NixOS and I only did .
oof -- that's pretty bad. it is adding /lib to the RPATH!!!!
This issue could be because you're on a system using FHS. is unset so that evals to an empty string. The series of makes the path go to the parent of which it doesn't do and just resolves as . So that results in it pulling from .

Yeah, that's what I suspected
llvm17 has a similar issue
Here's the root cause:
Sweet, I'll get started on a PR fixing this. If you can find any other affected versions, lmk.
looks like it is an issue all the way back to llvm12.