Dependencies

The kernel itself has very few runtime dependencies — it does not link against any user-space library — but the build pipeline depends on a number of host tools and the in-tree code makes use of vendored libraries.

Host build dependencies

The authoritative list is Documentation/process/changes.rst. Minimum versions in the current revision:

Tool	Minimum	Purpose
GNU make	4.0	Build driver
GCC	8.1	C compiler
Clang/LLVM	13.0.1	Optional C compiler
Rust (rustc)	1.78.0	CONFIG_RUST=y
bindgen	0.65	Rust binding generator
binutils	2.30	Linker, ar, objcopy
flex	recent	Kconfig parser
bison	recent	Kconfig parser
pkg-config	any	Auxiliary detection
util-linux	recent	mount, etc. (host tools)
kmod	27	modprobe, depmod
e2fsprogs	recent	Mounting ext file systems
jfsutils	optional	If you use jfs
btrfs-progs	optional	If you use btrfs
pcmciautils, quota, xfsprogs, nfs-utils, …	optional	Per-FS tools
openssl	1.1.1	Module signing
libelf	0.7	BTF generation
libcap	optional	Selftests
pahole	1.16	BTF generation
bc	any	A few scripts
Python	3.6	Documentation, scripts
Sphinx	2.4	make htmldocs
Perl	5.x	checkpatch and friends
zstd	1.4	Module/initramfs compression
ncurses-dev	any	menuconfig

For optional builds:

• PowerPC / arm64 / RISC-V SOC trees may need mkimage, dtc (vendored under scripts/dtc/).
• EFI tools: mokutil for managing platform keys.
• Documentation: sphinx-build, dot, plus theme packages.

In-tree vendored dependencies

A few dependencies are vendored into the source tree and built as part of the kernel:

• dtc — the device-tree compiler under scripts/dtc/.
• xz, zstd, lz4, lzo, zlib — decompression libraries under lib/ used by initramfs unpack and compressed swap.
• proc-macro2, quote, syn — Rust proc-macro support crates under rust/proc-macro2/, rust/quote/, rust/syn/. Vendored to control versions.
• pin-init — vendored Rust pinning crate under rust/pin-init/.
• libsubcmd, libtraceevent, libbpf — under tools/lib/, used by perf and bpftool.

In-kernel dependency graph

There is no formal graph — the kernel is a single binary — but the conceptual layering is:

graph TD
    H[include/]
    L[lib/]
    A[arch/]
    K[kernel/]
    M[mm/]
    C[crypto/]
    F[fs/]
    B[block/]
    N[net/]
    D[drivers/]
    S[security/]
    SO[sound/]
    V[virt/]
    R[rust/]
    IPC[ipc/]
    IOU[io_uring/]

    H -.headers.-> L
    H -.headers.-> A
    L --> K
    A --> K
    K --> M
    K --> C
    K --> S
    M --> F
    M --> B
    M --> N
    F --> B
    F --> IOU
    B --> D
    N --> D
    SO --> D
    V --> A
    V --> K
    R --> K
    IPC --> K
    IPC --> M
    S -.hooks.-> F
    S -.hooks.-> N
    S -.hooks.-> K

Bottom-up: include/ and arch/ provide types and primitives. lib/ provides data structures. kernel/ (and inside it, kernel/sched/) builds the process model. mm/ builds memory management on top. fs/, block/, net/, crypto/, sound/, security/, ipc/, io_uring/, virt/ build on those. drivers/ consumes all of them. rust/ is wired in alongside the C code.

External integrations

These are not "dependencies" in the build-system sense, but the kernel cooperates closely with:

• GNU C library, musl — consume the UAPI under include/uapi/.
• systemd, util-linux, kmod, e2fsprogs, btrfs-progs, xfsprogs, nfs-utils, samba/ksmbd-tools, iproute2, nftables, ethtool, bpftool, libbpf, perf, dracut, mkinitcpio — userspace counterparts.
• EFI firmware, ACPI, device-tree — enumeration and config sources.
• QEMU — both the in-kernel KVM target and a development environment.

Related pages

• Configuration — Kconfig.
• Tooling — checkpatch, sparse.
• Tools — perf, bpftool, libbpf vendored sources.