[LLDB] Issues running LLDB API and Shell tests on MacOS

[wizardengineer]

Summary

I wanted to mess around with the LLDB code base, it compiled perfectly fine and was able to run /bin/lldb in the build folder, but when it came to running ninja check-lldb-shell or ninja check-lldb-api, I ran in to several issues. I also create a fresh clone of LLVM without any code being modified, however, I still ran into the same issues shown below.

Environment

OS: macOS 15.3.1 24D70 arm64
Host: Mac14,7
Kernel: 24.3.0
Uptime: 1 day, 5 hours, 49 mins
Packages: 255 (brew)
Shell: zsh 5.9
Resolution: 1440x900
DE: Aqua
Terminal: ghostty
CPU: Apple M2
GPU: Apple M2
Memory: 1498MiB / 8192MiB

Commands

CMake

cmake -G Ninja \
  -DCMAKE_BUILD_TYPE=Release \
  -DLLVM_ENABLE_PROJECTS='clang;lldb;lld' \
  -DCMAKE_C_COMPILER=clang \
  -DCMAKE_CXX_COMPILER=clang++ \
  -DLLVM_TARGET_ARCH=AArch64 \
  -DLLVM_USE_LINKER=lld \ -C ../lldb/cmake/caches/Apple-lldb-macOS.cmake \
  -DLLVM_ENABLE_RUNTIMES='libcxx;libcxxabi;libunwind' \
  ../llvm

Ninja

Running ninja check-lldb-api:

Command Output (stdout):
--
lldb version 21.0.0git (https://github.com/wizardengineer/llvm-project.git revision b18e5b6a36399f11ba1152875b6892900c5afdaf)
  clang revision b18e5b6a36399f11ba1152875b6892900c5afdaf
  llvm revision b18e5b6a36399f11ba1152875b6892900c5afdaf

--
Command Output (stderr):
--
No entry for terminal type "xterm-ghostty";
using dumb terminal settings.
No entry for terminal type "xterm-ghostty";
using dumb terminal settings.
No entry for terminal type "xterm-ghostty";
using dumb terminal settings.
Traceback (most recent call last):
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/API/dotest.py", line 8, in <module>
    lldbsuite.test.run_suite()
    ~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 1042, in run_suite
    checkLibcxxSupport()
    ~~~~~~~~~~~~~~~~~~^^
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 799, in checkLibcxxSupport
    result, reason = canRunLibcxxTests()
                     ~~~~~~~~~~~~~~~~~^^
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 770, in canRunLibcxxTests
    from lldbsuite.test import lldbplatformutil
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py", line 11, in <module>
    from packaging import version
ModuleNotFoundError: No module named 'packaging'

--

Running ninja check-lldb-shell:

********************
FAIL: lldb-shell :: Settings/TestFrameFormatName.test (13 of 587)
******************** TEST 'lldb-shell :: Settings/TestFrameFormatName.test' FAILED ********************
Exit Code: 1

Command Output (stdout):
--
Cleaning TestFrameFormatName.test.tmp.out-names.o
Cleaning TestFrameFormatName.test.tmp.out

compiling names.cpp -> TestFrameFormatName.test.tmp.out-names.o
  STDOUT:

linking TestFrameFormatName.test.tmp.out-names.o -> TestFrameFormatName.test.tmp.out
  STDOUT:

  STDERR:
    dyld[85512]: Symbol not found: __ZdaPv
      Referenced from: <8A9B97F0-17A9-3203-AE08-5C5E06804A15> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
      Expected in:     <4C4C441E-5555-3144-A11A-55AB0A093AF7> /Users/juliusalexandre/GitDownloads/llvm-project/build/lib/libc++.1.0.dylib
    clang++: error: unable to execute command: Abort trap: 6
    clang++: error: linker command failed due to signal (use -v to see invocation)


--
Command Output (stderr):
--
RUN: at line 4: '/opt/homebrew/opt/python@3.13/bin/python3.13' /Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/Shell/helper/build.py --compiler=any --arch=64 --tools-dir=/Users/juliusalexandre/GitDownloads/llvm-project/build/./bin --libs-dir=/Users/juliusalexandre/GitDownloads/llvm-project/build/./lib /Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/Shell/Settings/Inputs/names.cpp --std c++17 -o /Users/juliusalexandre/GitDownloads/llvm-project/build/tools/lldb/test/Shell/Settings/Output/TestFrameFormatName.test.tmp.out
+ /opt/homebrew/opt/python@3.13/bin/python3.13 /Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/Shell/helper/build.py --compiler=any --arch=64 --tools-dir=/Users/juliusalexandre/GitDownloads/llvm-project/build/./bin --libs-dir=/Users/juliusalexandre/GitDownloads/llvm-project/build/./lib /Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/Shell/Settings/Inputs/names.cpp --std c++17 -o /Users/juliusalexandre/GitDownloads/llvm-project/build/tools/lldb/test/Shell/Settings/Output/TestFrameFormatName.test.tmp.out

--

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Julius Alexandre (wizardengineer)

## Summary

I wanted to mess around with the LLDB code base, it compiled perfectly fine and was able to run /bin/lldb in the build folder, but when it came to running ninja check-lldb-shell or ninja check-lldb-api, I ran in to several issues shown below.

Environment

OS: macOS 15.3.1 24D70 arm64
Host: Mac14,7
Kernel: 24.3.0
Uptime: 1 day, 5 hours, 49 mins
Packages: 255 (brew)
Shell: zsh 5.9
Resolution: 1440x900
DE: Aqua
Terminal: ghostty
CPU: Apple M2
GPU: Apple M2
Memory: 1498MiB / 8192MiB

Commands

CMake

cmake -G Ninja \
  -DCMAKE_BUILD_TYPE=Release \
  -DLLVM_ENABLE_PROJECTS='clang;lldb;lld' \
  -DCMAKE_C_COMPILER=clang \
  -DCMAKE_CXX_COMPILER=clang++ \
  -DLLVM_TARGET_ARCH=AArch64 \
  -DLLVM_USE_LINKER=lld \ -C ../lldb/cmake/caches/Apple-lldb-macOS.cmake \
  -DLLVM_ENABLE_RUNTIMES='libcxx;libcxxabi;libunwind' \
  ../llvm

Ninja

Running ninja check-lldb-api:

Command Output (stdout):
--
lldb version 21.0.0git (https://github.com/wizardengineer/llvm-project.git revision b18e5b6a36399f11ba1152875b6892900c5afdaf)
  clang revision b18e5b6a36399f11ba1152875b6892900c5afdaf
  llvm revision b18e5b6a36399f11ba1152875b6892900c5afdaf

--
Command Output (stderr):
--
No entry for terminal type "xterm-ghostty";
using dumb terminal settings.
No entry for terminal type "xterm-ghostty";
using dumb terminal settings.
No entry for terminal type "xterm-ghostty";
using dumb terminal settings.
Traceback (most recent call last):
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/API/dotest.py", line 8, in <module>
    lldbsuite.test.run_suite()
    ~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 1042, in run_suite
    checkLibcxxSupport()
    ~~~~~~~~~~~~~~~~~~^^
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 799, in checkLibcxxSupport
    result, reason = canRunLibcxxTests()
                     ~~~~~~~~~~~~~~~~~^^
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 770, in canRunLibcxxTests
    from lldbsuite.test import lldbplatformutil
  File "/Users/juliusalexandre/GitDownloads/llvm-project/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py", line 11, in <module>
    from packaging import version
ModuleNotFoundError: No module named 'packaging'

--

Running ninja check-lldb-shell:

********************
FAIL: lldb-shell :: Settings/TestFrameFormatName.test (13 of 587)
******************** TEST 'lldb-shell :: Settings/TestFrameFormatName.test' FAILED ********************
Exit Code: 1

Command Output (stdout):
--
Cleaning TestFrameFormatName.test.tmp.out-names.o
Cleaning TestFrameFormatName.test.tmp.out

compiling names.cpp -> TestFrameFormatName.test.tmp.out-names.o
  STDOUT:

linking TestFrameFormatName.test.tmp.out-names.o -> TestFrameFormatName.test.tmp.out
  STDOUT:

  STDERR:
    dyld[85512]: Symbol not found: __ZdaPv
      Referenced from: <8A9B97F0-17A9-3203-AE08-5C5E06804A15> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
      Expected in:     <4C4C441E-5555-3144-A11A-55AB0A093AF7> /Users/juliusalexandre/GitDownloads/llvm-project/build/lib/libc++.1.0.dylib
    clang++: error: unable to execute command: Abort trap: 6
    clang++: error: linker command failed due to signal (use -v to see invocation)


--
Command Output (stderr):
--
RUN: at line 4: '/opt/homebrew/opt/python@<!-- -->3.13/bin/python3.13' /Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/Shell/helper/build.py --compiler=any --arch=64 --tools-dir=/Users/juliusalexandre/GitDownloads/llvm-project/build/./bin --libs-dir=/Users/juliusalexandre/GitDownloads/llvm-project/build/./lib /Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/Shell/Settings/Inputs/names.cpp --std c++17 -o /Users/juliusalexandre/GitDownloads/llvm-project/build/tools/lldb/test/Shell/Settings/Output/TestFrameFormatName.test.tmp.out
+ /opt/homebrew/opt/python@<!-- -->3.13/bin/python3.13 /Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/Shell/helper/build.py --compiler=any --arch=64 --tools-dir=/Users/juliusalexandre/GitDownloads/llvm-project/build/./bin --libs-dir=/Users/juliusalexandre/GitDownloads/llvm-project/build/./lib /Users/juliusalexandre/GitDownloads/llvm-project/lldb/test/Shell/Settings/Inputs/names.cpp --std c++17 -o /Users/juliusalexandre/GitDownloads/llvm-project/build/tools/lldb/test/Shell/Settings/Output/TestFrameFormatName.test.tmp.out

--

[Michael137]

Re. the API test

ModuleNotFoundError: No module named 'packaging'

You just need to pip install the appropriate python module. If you configure CMake with -DLLDB_ENFORCE_STRICT_TEST_REQUIREMENTS=ON, you'll be told what modules are missing at configuration time

[Michael137]

The shell-test failure is worrying. I wonder if this is related to #109549 somehow. Though in this case it's just the plain operator delete symbol it can't find, whereas in the other issue it's the typed allocator.

If you try to compile any test program with your locally built clang, are you able to run that program? If it fails in the same way, could you paste the output of your ./path/to/local/clang++ main.cpp -g -###?

[adrian-prantl]

You just need to pip install the appropriate python module. If you configure CMake with -DLLDB_ENFORCE_STRICT_TEST_REQUIREMENTS=ON, you'll be told what modules are missing at configuration time

@wizardengineer Can you check whether this is documented (e.g. here: https://lldb.llvm.org/resources/build.html) and potentially open a PR to add this?

[wizardengineer]

Re. the API test

ModuleNotFoundError: No module named 'packaging'

You just need to pip install the appropriate python module. If you configure CMake with -DLLDB_ENFORCE_STRICT_TEST_REQUIREMENTS=ON, you'll be told what modules are missing at configuration time

Strangely enough that didn't really work, I ran into the same issues. I had to resort in to using brew install python-packaging instead.

[wizardengineer]

@Michael137

The shell-test failure is worrying. I wonder if this is related to #109549 somehow.

It does seem like a similar issue, I would assume it relates?

EDIT:
here's more of the ninja check-lldb-api output, seems to be similar to #109549 like you said

check-lldb-api output

dyld[46747]: symbol '__ZnamSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /System/Library/PrivateFrameworks/AppleFlatBuffers.framework/Versions/A/AppleFlatBuffers is being set to 0xBAD4007.
dyld[46747]: symbol '__ZdlPvSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /System/Library/PrivateFrameworks/AppleFlatBuffers.framework/Versions/A/AppleFlatBuffers is being set to 0xBAD4007.
dyld[46747]: symbol '__ZdaPvSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /System/Library/PrivateFrameworks/AppleFlatBuffers.framework/Versions/A/AppleFlatBuffers is being set to 0xBAD4007.
dyld[46747]: symbol '__ZnwmSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /System/Library/PrivateFrameworks/SentencePieceInternal.framework/Versions/A/SentencePieceInternal is being set to 0xBAD4007.
dyld[46747]: symbol '__ZnamSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /System/Library/PrivateFrameworks/SentencePieceInternal.framework/Versions/A/SentencePieceInternal is being set to 0xBAD4007.
dyld[46747]: symbol '__ZdlPvSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /System/Library/PrivateFrameworks/SentencePieceInternal.framework/Versions/A/SentencePieceInternal is being set to 0xBAD4007.
dyld[46747]: symbol '__ZdaPvSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /System/Library/PrivateFrameworks/SentencePieceInternal.framework/Versions/A/SentencePieceInternal is being set to 0xBAD4007.
dyld[46747]: symbol '__ZnwmSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /System/Library/PrivateFrameworks/CoreSceneUnderstanding.framework/Versions/A/CoreSceneUnderstanding is being set to 0xBAD4007.
dyld[46747]: symbol '__ZnamSt19__type_descriptor_t' missing from root that overrides /usr/lib/libc++abi.dylib. Use of that symbol in /System/Library/PrivateFrameworks/CoreSceneUnderstanding.framework/Versions/A/CoreSceneUnderstanding is being set to 0xBAD4007.
...

If you try to compile any test program with your locally built clang, are you able to run that program? If it fails in the same way, could you paste the output of your ./path/to/local/clang++ main.cpp -g -###?

Wasn't able to compile the nor run the code.
The Code:

#include <iostream>
int main() { return {}; }

After running ./bin/clang++ -g -### simple-test-clang-linker.cpp, I got this:

Clang Output

-project.git b18e5b6a36399f11ba1152875b6892900c5afdaf)
Target: arm64-apple-darwin24.3.0
Thread model: posix
InstalledDir: /Users/juliusalexandre/GitDownloads/llvm-project/lldb-build/bin
Build config: +assertions
 "/Users/juliusalexandre/GitDownloads/llvm-project/lldb-build/bin/clang-21" "-cc1" "-triple" "arm64-apple-macosx15.0.0" "-Wundef-prefix=TARGET_OS_" "-Werror=undef-prefix" "-Wdeprecated-objc-isa-usage" "-Werror=deprecated-objc-isa-usage" "-emit-obj" "-dumpdir" "simple-test-clang-linker-" "-disable-free" "-clear-ast-before-backend" "-main-file-name" "simple-test-clang-linker.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mframe-pointer=non-leaf" "-ffp-contract=on" "-fno-rounding-math" "-funwind-tables=1" "-fcompatibility-qualified-id-block-type-checking" "-fvisibility-inlines-hidden-static-local-var" "-fbuiltin-headers-in-system-modules" "-fdefine-target-os-macros" "-enable-tlsdesc" "-target-cpu" "apple-m1" "-target-feature" "+zcm" "-target-feature" "+zcz" "-target-feature" "+v8.4a" "-target-feature" "+aes" "-target-feature" "+altnzcv" "-target-feature" "+ccdp" "-target-feature" "+ccpp" "-target-feature" "+complxnum" "-target-feature" "+crc" "-target-feature" "+dotprod" "-target-feature" "+flagm" "-target-feature" "+fp-armv8" "-target-feature" "+fp16fml" "-target-feature" "+fptoint" "-target-feature" "+fullfp16" "-target-feature" "+jsconv" "-target-feature" "+lse" "-target-feature" "+neon" "-target-feature" "+pauth" "-target-feature" "+perfmon" "-target-feature" "+predres" "-target-feature" "+ras" "-target-feature" "+rcpc" "-target-feature" "+rdm" "-target-feature" "+sb" "-target-feature" "+sha2" "-target-feature" "+sha3" "-target-feature" "+specrestrict" "-target-feature" "+ssbs" "-target-abi" "darwinpcs" "-debug-info-kind=standalone" "-dwarf-version=5" "-debugger-tuning=lldb" "-fdebug-compilation-dir=/Users/juliusalexandre/GitDownloads/llvm-project/lldb-build" "-target-linker-version" "1053.12" "-fcoverage-compilation-dir=/Users/juliusalexandre/GitDownloads/llvm-project/lldb-build" "-resource-dir" "/Users/juliusalexandre/GitDownloads/llvm-project/lldb-build/lib/clang/21" "-internal-isystem" "/Users/juliusalexandre/GitDownloads/llvm-project/lldb-build/bin/../include/c++/v1" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/Users/juliusalexandre/GitDownloads/llvm-project/lldb-build/lib/clang/21/include" "-internal-externc-isystem" "/usr/include" "-fdeprecated-macro" "-ferror-limit" "19" "-stack-protector" "1" "-fblocks" "-fencode-extended-block-signature" "-fregister-global-dtors-with-atexit" "-fgnuc-version=4.2.1" "-fskip-odr-check-in-gmf" "-fcxx-exceptions" "-fexceptions" "-fmax-type-align=16" "-fcolor-diagnostics" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" "/var/folders/8x/5_z9pgmj61n5mcfm8g4n4vmc0000gn/T/simple-test-clang-linker-b99fa3.o" "-x" "c++" "simple-test-clang-linker.cpp"        "/usr/bin/ld" "-demangle" "-lto_library" "/Users/juliusalexandre/GitDownloads/llvm-project/lldb-build/lib/libLTO.dylib" "-no_deduplicate" "-dynamic" "-arch" "arm64" "-platform_version" "macos" "15.0.0" "15.0.0" "-mllvm" "-enable-linkonceodr-outlining" "-o" "simple-test-clang-linker" "/var/folders/8x/5_z9pgmj61n5mcfm8g4n4vmc0000gn/T/simple-test-clang-linker-b99fa3.o" "-lc++" "-lSystem"

[wizardengineer]

Can you check whether this is documented (e.g. here: https://lldb.llvm.org/resources/build.html) and potentially open a PR to add this?

@adrian-prantl

great catch :), I'm assuming you were referring the cmake flag, if so, I didn't see anything relating to -DLLDB_ENFORCE_STRICT_TEST_REQUIREMENTS=ON. Later on I'll make sure to create a PR.

[wizardengineer]

Okay, so I had to resort to a unconventional solution for getting the ninja check-lldb-shell to work, it doesn't seem a simple pip3 install xyz worked. I had to create a virtual env for python, then install all the packages. If not, even after doing pip install xyz, it'd still consider it missing. I'm not sure if I'm the only one having this issue, but it seems like there's conflicts when it comes to what python3 executable that the build system uses. Leading me to do

-DPython3_EXECUTABLE=/Users/juliusalexandre/venv-packaging/bin/python3

which solved my issue.

the former or original python3 path was /opt/homebrew/Frameworks/Python.framework/Versions/3.13/bin/python3.13. Doing a pip3 install xyz only affected other external python3 executables, like the ones in /usr/bin/python3 and /opt/homebrew/bin/python3. So it never really installed in the path the build system adhere too. Even changing to -DPython3_EXECUTABLE to those paths, didn't work.

I couldn't even do something as such:

❯ /opt/homebrew/Frameworks/Python.framework/Versions/3.13/bin/pip3 install psutil pygments PyYAML
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try brew install
    xyz, where xyz is the package you are trying to
    install.

    If you wish to install a Python library that isn't in Homebrew,                                    use a virtual environment:

    python3 -m venv path/to/venv
    source path/to/venv/bin/activate
    python3 -m pip install xyz
                                                                                                       If you wish to install a Python application that isn't in Homebrew,
    it may be easiest to use 'pipx install xyz', which will manage a
    virtual environment for you. You can install pipx with

    brew install pipx
    You may restore the old behavior of pip by passing                                                 the '--break-system-packages' flag to pip, or by adding
    'break-system-packages = true' to your pip.conf file. The latter
    will permanently disable this error.

    If you disable this error, we STRONGLY recommend that you additionally
    pass the '--user' flag to pip, or set 'user = true' in your pip.conf
    file. Failure to do this can result in a broken Homebrew installation.

    Read more about this behavior here: <https://peps.python.org/pep-0668/>

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

I don't know if this is an issue on my part, I haven't seen anyone else encounter this same issue. But using the virtual env then installing the packages solved the ninja check-lldb-shell errors.