solana-lldb fails with libncurses.so.6 / NCURSES6_5.0.19991023 not found — platform-tools binaries are built against Ubuntu 20.04
Symptom: source-level debugging of an SBF program gets as far as building the .debug file and running solana-ledger-tool program run, then solana-lldb dies with ./lldb: error while loading shared libraries: libncurses.so.6: cannot open shared object file. Symlinking a modern distro ncurses produces a second, weirder error: /usr/lib/libpanel.so.6: version 'NCURSES6_5.0.19991023' not found (required by .../platform-tools/llvm/bin/../lib/liblldb.so.15-rust-dev).
Cause: the prebuilt lldb inside solana-labs/platform-tools is compiled and released on Ubuntu 20.04 and links against that distro's ncurses build, whose version symbols do not exist in newer distro packages (Arch, recent Fedora/Ubuntu). This is a binary-compatibility problem, not a missing package — installing ncurses on the host cannot fix it.
Fix: run the debugger inside a matching container rather than fighting host libraries:
FROM ubuntu:20.04 RUN apt-get update && apt-get install -y wget python3-dev libxml2 RUN cd /root && mkdir -p .cache/solana/v1.37/platform-tools && \ wget "https://github.com/solana-labs/platform-tools/releases/download/v1.37/platform-tools-linux-x86_64.tar.bz2" && \ tar jxf platform-tools-linux-x86_64.tar.bz2 -C /root/.cache/solana/v1.37/platform-tools
Mount your program and ledger into the container and solana-lldb works. Adjust the platform-tools version to the one your Solana/Agave toolchain expects (cargo build-sbf --version reports it) and unpack it into that exact cache path. Newer platform-tools releases may be built on a newer base image, so try the host first and fall back to the container only if the ncurses symbols mismatch.
Source: adapted from a Stack Exchange answer by Maxim Schmidt (question by Maxim Schmidt), https://solana.stackexchange.com/questions/9565/source-level-debugging-fails-due-to-missing-ncurses-library — CC BY-SA 4.0
Tested platform-tools v1.37 lldb (15.0.7-rust-dev) on an Ubuntu 24.04 host. The symlink failure reproduces exactly: libncurses.so.6/libpanel.so.6 symlinked to the wide libncursesw/libpanelw gives "version 'NCURSES6_5.0.19991023' not found (required by .../liblldb.so.15-rust-dev)". But on Debian/Ubuntu, installing the right package does fix it. The non-wide ncurses still exists as package libncurses6 (noble: 6.4+20240113-1ubuntu2), and its libpanel.so.6 defines NCURSES6_5.0.19991023 (readelf -V). With those libs on LD_LIBRARY_PATH the ncurses errors are gone. ldd also shows a second hard dependency the post doesn't mention: libpython3.8.so.1.0, which noble doesn't package. A uv-managed CPython 3.8.20 supplies it (LD_LIBRARY_PATH=<py38>/lib, PYTHONHOME=<py38>), and lldb's Python glue also needs 'six' on PYTHONPATH. With all of that, 'lldb -b -o "script print(lldb.SBDebugger.GetVersionString())"' works on the host. So: libncurses6 + a Python 3.8 + six on Debian/Ubuntu. The 20.04 container is still the simpler route on distros without non-wide ncurses.