Change:
On Darwin, lldb is unable to locate the support binaries directory. Trying to run lldb with a target executable results in it failing with . a target the target Successfully runs the target executable. The problem is Darwin specific because of the way lldb locates the directory. It expects the and to be present in the same directory as indicated in the comment . As part of the derivation is a separate output, it cannot locate the directory and fails to run the executable.
Can confirm, macos 10.15.
Yes and I have to manually set also.
Problem perists:
are you getting it to work with that? No luck here:
Use instead of . The former one does not contain the output, so you can use an environment variable.
What would be the preferable solution from an LLVM maintainers perspective? The lib output could be dropped, or LLVM would need to be patched to look for the support binaries in the correct path.
I would suggest a LLVM patch that could be general enough that we could send back to upstream, worst case, we can reassemble an out and lib just for this usecase in the meantime for Darwin.
are you sure it should be fixed on LLVM side? Because lldb from homebrew works fine on macos.
The fix is probably similar to what I did for LTO support (using to hardcode the path to the correct location in the store).
Here is the homebrew formula:
I’m working on a patch. The fix is to combine and on Darwin. It’s not possible to patch LLDB to know the location of because that creates a cycle between the two outputs.
I created It doesn’t exhibit the problem, but it also doesn’t seem to work. It may be that this is as good as it can get without the requisite entitlements.
lldb from your PR seems to work for me, even when I unset (my workaround for the prior issues). What wasn't working for you?
When I follow the steps you provided in , I get the following result: It only works if I don’t set .
Reopening because the change is technically breaking, and we’re in a breaking change freeze before the release.
Note that if you do need this, you can cherry-pick my commit from .
Yes, I see that error with my own MRE (haha) if I set to the nix version; it works with (which I assume is the default anyway).
When will this feature typically merged from master to unstable branch?
Nvm, just noticed that it was reverted :/
I had to revert because there is a freeze on breaking changes until 24.05 is released. Once 24.05 is released, I’ll reopen the fix PR.
I've used the commit you mentioned in previous comments. Thank you!
Just want to check some updates. Is this issue solved in 24.05?
It would be a breaking change, so it’d have to target unstable/24.11.
I resubmitted the lldb fix as

Discussion:
cp $out/lib/* $out/share/adapter cp -r adapter/scripts $out/share/adapter cp -t $out/share/formatters formatters/*.py <del> ln -s ${lldb.lib} $out/share/lldb </del> <ins> ln -s ${lib.getLib lldb} $out/share/lldb </ins> makeWrapper $out/share/adapter/codelldb $out/bin/codelldb  --set-default LLDB_DEBUGSERVER_PATH "${lldb.out}/bin/lldb-server" '';

src = src'; inherit patches; <del> outputs = [ "out" "lib" "dev" ]; </del> <ins> # LLDB expects to find the path to `bin` relative to `lib` on Darwin. It can’t be patched with the location of # the `lib` output because that would create a cycle between it and the `out` output. outputs = [ "out" "dev" ] ++ lib.optionals (!stdenv.isDarwin) [ "lib" ]; </ins> sourceRoot = lib.optional (lib.versionAtLeast release_version "13") "${src.name}/${pname}";