Illustration representing compiling XNNPACK from source on Linux

Linux has the fewest moving parts of any XNNPACK build target — the same toolchain most developers already have installed for general C/C++ work is usually enough. This guide covers Debian/Ubuntu-family and Fedora-family systems.

Installing prerequisites

Debian / Ubuntu

sudo apt update
sudo apt install build-essential cmake ninja-build python3 git

Fedora

sudo dnf install gcc gcc-c++ cmake ninja-build python3 git

Getting the source

Either extract the archive from the Download section or clone the repository if you want Git history:

git clone https://github.com/google/XNNPACK.git
cd XNNPACK

Configuring the build

A basic Release configuration with Ninja looks like this:

cmake -S . -B build -G Ninja \
  -DCMAKE_BUILD_TYPE=Release \
  -DXNNPACK_BUILD_TESTS=OFF \
  -DXNNPACK_BUILD_BENCHMARKS=OFF

Turning off tests and benchmarks noticeably shortens build time if you only need the library itself, since XNNPACK's test suite is large.

Building

cmake --build build -j$(nproc)

The -j$(nproc) flag tells Ninja to use every available CPU core, which matters here — XNNPACK generates and compiles a large number of architecture-specific micro-kernel files.

Cross-compiling for ARM

If you're building on an x86-64 Linux machine but targeting an ARM device, you'll need an appropriate cross-compilation toolchain file passed to CMake via -DCMAKE_TOOLCHAIN_FILE. This is common when preparing binaries for embedded Linux boards or Android, where the build host and the run target are different architectures.

Verifying the build

If you left tests enabled, running the generated test binaries is the fastest way to confirm the build is healthy before linking it into a larger project. A failing test on an unsupported instruction set for your CPU is expected and not necessarily a build problem — see the compatibility notes on the homepage for which instruction sets your hardware actually supports.