Triton's cmake flags decide whether LLVM lifting exists in your build

A five step Python session holds the whole mental model

The documented entry point creates a context for one architecture, optionally pins a concrete value and optionally names a register symbolically, then feeds raw instruction bytes through a processing call and reads back a symbolic expression.

from triton import *

>>> # Create the Triton context with a defined architecture
>>> ctx = TritonContext(ARCH.X86_64)

>>> # Define concrete values (optional)
>>> ctx.setConcreteRegisterValue(ctx.registers.rip, 0x40000)

>>> # Symbolize data (optional)
>>> ctx.symbolizeRegister(ctx.registers.rax, 'my_rax')

>>> # Execute instructions
>>> ctx.processing(Instruction(b"\x48\x35\x34\x12\x00\x00")) # xor rax, 0x1234
>>> ctx.processing(Instruction(b"\x48\x89\xc1")) # mov rcx, rax

>>> # Get the symbolic expression
>>> rcx_expr = ctx.getSymbolicRegister(ctx.registers.rcx)

The library keeps the concrete and symbolic layers separate by design, and the caller owns the boundary between them.

libcapstone is the one dependency you cannot switch off

The dependency table is short and the flags on it matter more than the version numbers:

* libcapstone                >= 5.0.x   https://github.com/capstone-engine/capstone
* libboost      (optional)   >= 1.68
* libpython     (optional)   >= 3.6
* libz3         (optional)   >= 4.6.0   https://github.com/Z3Prover/z3
* libbitwuzla   (optional)   >= 0.4.x   https://github.com/bitwuzla/bitwuzla
* llvm          (optional)   >= 12

Only libcapstone carries no optional marker, because it is the disassembler the semantics are layered on. Everything else is opt in, and each one buys a specific capability: LLVM for lifting, Z3 and Bitwuzla as SMT solvers, Python for the Python API. The README also offers a one line install, `pip install triton-library`.

The default cmake line compiles out LLVM and Bitwuzla

The source build is six commands on Linux and macOS:

$ git clone https://github.com/JonathanSalwan/Triton
$ cd Triton
$ mkdir build ; cd build
$ cmake ..
$ make -j3
$ sudo make install

That sequence produces a working library and quietly leaves two capabilities out. LLVM and Bitwuzla are not compiled unless you ask, and the flags to ask are:

$ cmake -DLLVM_INTERFACE=ON -DCMAKE_PREFIX_PATH=$(llvm-config --prefix) -DBITWUZLA_INTERFACE=ON ..

The same choice is written a second time in setup.py as four module level constants, where `Z3_INTERFACE = ON` sits above `LLVM_INTERFACE = OFF`, `BITWUZLA_INTERFACE = OFF` and `BOOST_INTERFACE = OFF`. Edit those or pass the flags; leave them and you have the reduced build.

The Dockerfile asks for more than the version table does

The container recipe is the most opinionated document in the repository, and it contradicts the minimums above it. The Dockerfile starts from `ubuntu:24.04` and pins its own floors in comments: libboost >= 1.83, libpython >= 3.12 and llvm >= 16.0, then installs llvm-16 and llvm-16-dev, ninja-build and libgmp-dev. The dependency table permits boost 1.68, python 3.6 and llvm 12. Further down it wants cmake >= 3.20 and libz3 >= 4.13.0 against a documented minimum of 4.6.0.

It also builds two dependencies from source rather than trusting a package: Capstone from the 5.0.1 tarball and Bitwuzla from a git clone. The Python side gets a virtual environment at `/Triton-venv` and `pip install cmake lief meson setuptools unicorn z3-solver`.

Read that as the known good combination rather than as excess. The version table states what the code is expected to tolerate; the container encodes what someone actually built against. If you hit a compile error near the floor of the table, move to the container's versions before you start bisecting your own toolchain.

Could NOT find PythonLibs is the failure with a documented fix

One compile failure is written out in full, and it is the macOS on Apple Silicon case. The symptom is cmake output reading:

Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS)

The fix is to hand cmake three paths for your specific Python version:

cmake -DCMAKE_INSTALL_PREFIX=/opt/homebrew/ \
      -DPYTHON_EXECUTABLE=/opt/homebrew/bin/python3 \
      -DPYTHON_LIBRARIES=/opt/homebrew/Cellar/[email protected]/3.10.8/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib \
      -DPYTHON_INCLUDE_DIRS=/opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.10/include/python3.10/ \
      ..

The hardcoded paths are the weak part of that advice, since they encode one Homebrew prefix and one 3.10 patch release. The way to get your own is a three line call:

from sysconfig import get_paths
info = get_paths()
print(info)

Note what the fix implies. Once PythonLibs is missing you have no bindings, so this is a warning to take before writing the analysis that depends on them.

Editor hints require a .pyi file next to the shared object

If Python autocompletion is not working, the README says to generate a stub file. Two steps fix it: execute `doc/autocomplete/generate_autocomplete.py`, then place the generated triton.pyi file in the same directory as the Triton shared object you want hints for, with `/usr/lib/python3.13/` given as the example location. Your editor has to support parsing .pyi files.

One consequence follows for day to day work: the location requirement means a virtual environment, a system interpreter and a custom install prefix each need their own copy of the stub, since the hint is found by sitting next to the library rather than by being importable from a package.

This is the sort of friction that does not show up in an installation log. It shows up as a red squiggle under every attribute access.

Windows offers cmake, setup.py and prebuilt artefacts, each with a bill

Three routes exist and each one asks for something different. You can use cmake to generate the `.sln` file of libTriton, with the generator set to `Visual Studio 14 2015 Win64` and the dependency roots passed as `BOOST_ROOT`, `PYTHON_INCLUDE_DIRS`, `PYTHON_LIBRARIES`, `Z3_INCLUDE_DIRS`, `Z3_LIBRARIES`, `CAPSTONE_INCLUDE_DIRS` and `CAPSTONE_LIBRARIES`. That is the most explicit route and the most path heavy.

The debug binding goes through setup.py instead, and the environment has to be primed first:

> git clone https://github.com/JonathanSalwan/Triton.git
> cd Triton
> $env:COMPILER_DIR="C:/deps/llvm/llvm2116r/bin"
> $env:CMAKE_PREFIX_PATH="C:/deps/llvm/llvm-project-21.1.6.src/install/lib/cmake/llvm;C:/code/cxx-common-cmake/build/install"
> python_d -m build --wheel
> python_d -m pip install (Get-ChildItem .\dist\triton_library*)

The third route avoids the compiler entirely: precompiled builds sit in AppVeyor's artefacts history. The catch is named outright, those artefacts probably need the Visual C++ Redistributable packages for Visual Studio 2012 installed on the target machine. A prebuilt library that drags a decade old runtime onto a current desktop is a cost worth pricing before you take it.

vcpkg keeps the port current, and the release tags do not

The vcpkg port is the tidiest install path on Windows, and its freshness is somebody else's job:

$ git clone https://github.com/Microsoft/vcpkg.git
$ cd vcpkg
$ ./bootstrap-vcpkg.sh  # ./bootstrap-vcpkg.bat for Windows
$ ./vcpkg integrate install
$ ./vcpkg install triton

The port is kept up to date by Microsoft team members and community contributors, and the escape hatch when it drifts is explicit: open an issue or a pull request on the vcpkg repository. That is a shared queue rather than a guarantee, so `vcpkg install triton` can hand you an older Triton than the one you were reading about.

The same gap shows up in the project's own version numbers. setup.py declares `VERSION_MAJOR = 1`, `VERSION_MINOR = 0`, `VERSION_PATCH = 0` and `RELEASE_CANDIDATE = 4`, which composes into 1.0.0rc4, and a dev-v1.0 branch is linked from the README. The newest tagged release is still v0.9 from 2022-02-09, after v0.8.1 in 2020 and v0.8 in April 2020. The last push landed on 2026-10-31, so the source moves while the tags do not. Code is under the Apache 2.0 license, which makes the version skew a packaging question rather than a legal one.

Editorial conclusion

Triton fits a team writing its own analysis tooling on top of an AST rather than consuming an off the shelf reverse engineering UI, and it is a poor fit if you want a stable 1.0 with a support commitment, since the newest tagged release is still v0.9 from 2022-02-09 while the source is at 1.0.0rc4. Decide before you build whether you need LLVM lifting and Bitwuzla, because the default `cmake ..` compiles without both. Read setup.py first: Z3_INTERFACE, LLVM_INTERFACE, BITWUZLA_INTERFACE and BOOST_INTERFACE are module level constants you are expected to edit, not command line switches.

Frequently asked questions

Official sources

1. JonathanSalwan/Triton on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases