[Lldb-commits] [lldb] [lldb] Add an option to build liblldb statically (PR #223210)

[Anutosh Bhat via lldb-commits]

anutosh491 wrote:

> Thanks for the explanations. I'm fine with the static build since that seems like the best option for Emscripten.
>
> I've left a few comments inline. Besides those, I have one larger question: What's the plan for testing `LLDB_BUILD_STATIC_LIBLLDB` going forward? Build logic may get changed at any time, and if there's no CI actively testing this, you'll be on your own fixing the Emscripten support when it breaks.

For testing, I plan to maintain an Emscripten-based LLDB package through [emscripten-forge](https://github.com/emscripten-forge/recipes), where I’m also a maintainer. The recipe CI will configure this path, build and install the static LLDB archives, link a separate SB API consumer against the installed package, and execute that consumer with Node. This should catch both build-system regressions and packages that build successfully but cannot actually be consumed.

For some context, emscripten-forge is essentially a conda-forge-style ecosystem for Emscripten. It was created at QuantStack, where I work & we are the main maintainers behind Project Jupyter (Jupyter Notebooks, kernels etc). 
It was built to support projects such as [JupyterLite](https://github.com/jupyterlite/jupyterlite), an in-browser distribution of JupyterLab powered by WebAssembly. It now helps bring languages including Python, C++, R, Fortran, OCaml and Haskell to JupyterLite, running entirely in the browser.

I did much of the work involved in bringing C++ to JupyterLite. That included porting [Clang-Repl](https://clang.llvm.org/docs/ClangRepl.html) to WebAssembly and packaging browser builds of LLVM, Clang and LLD through emscripten-forge.

You can [try the C++ notebook in Jupyterlite here](https://notebook.link/@quantstack/xeus-cpp), or see my [FOSDEM 2026 LLVM talk](https://archive.fosdem.org/2026/schedule/event/QX3RPH-building_interactive_cc_workflows_in_jupyter_through_clang-repl/) about that work. @JDevlieghere was at the talk too :)

Now I’m working on WasmBolt, which aims to provide a playground for the broader LLVM toolchain entirely inside the browser. Clang, LLVM, MLIR, LLD and Graphviz are already running there, so LLDB is the next natural step.

Here is the a very early LLDB prototype (also requires lldb-dap to wasm):


https://github.com/user-attachments/assets/29ff1c51-9b6a-4fa4-b21c-6f84a31f12b2



The prototype builds `liblldb` for Emscripten and uses its SB API to debug a WebAssembly program running through WAMR. I’m also experimenting with an Emscripten build of `lldb-dap` as a possible frontend integration, although that is separate from this static-library patch.

The immediate plan is therefore to keep the complete build-and-consume workflow tested continuously through emscripten-forge, while exploring a lightweight upstream check once this support settles.

Hopefully this addressed your concern regarding testing !

We have also had integration opportunities for eg clang-repl or mlir python bindings being built for wasm which need numpy built for wasm at runtime. And now finally WasmBolt. All these libs/pkgs/tools can be fetched out of emscripten-forge through a channel using a package manager.

1) So we have a yaml file to begin with 
```
name: lldb-env
channels:
  - emscripten-forge
dependencies:
  - lldb
  - clang
  - opt
```

That's all what Wasmbolt would be doing as can be seen [here](https://github.com/anutosh491/WasmBolt/blob/main/environment-wasm-host.yml)

2) And then make the environment using a package manager like micromamba or pixi 
```
micromamba create  -f environment-wasm-host.yml --platform=emscripten-wasm32
```

That's all you would need to get access to an emscripten wasm build of lldb and you can put it to use then. The lldb community could let me know if they'd be interested in the same & we could host a live playground having lldb working for the latest release very quickly !

I'm also interested in hosting the swift compiler & the lldb based swift-repl on emscripten-forge in the future. https://swiftwasm.org/ editor runs on a FaaS I think. So it compiles Swift for WebAssembly, but the Swift compiler itself is not running as WebAssembly in the browser .. which is what would be fixed.

https://github.com/llvm/llvm-project/pull/223210