libcpuid: a small C library for identifying the CPU you are running on

What libcpuid is for

libcpuid is described as a small C library for x86 CPU detection and feature extraction, and the README opens by saying simply that libcpuid provides CPU identification, with the project website hosted on SourceForge.

That is the whole scope, and it is a scope that turns out to have real depth. Knowing the vendor and the model of a processor is a table lookup. Knowing which instruction set extensions it supports, whether the topology is symmetric, what the cache hierarchy looks like, whether the CPU has certain features such as hardware AES or the various virtualisation extensions, and reading the model specific registers that hold that information, is a considerably larger job with a lot of per-vendor quirks.

The audience is code that has to make a runtime decision based on the machine it is running on. A media application choosing a SIMD path, a build system deciding which code path to compile in, a virtualisation layer checking for the right hardware support, a system monitor reporting what the processor can do, each of these ends up needing the same answers.

The library supports two architectures. For x86 there are the 32-bit CPUs, IA-32, also known as i386, i486, i586 and i686, and the 64-bit CPUs, x86_64, also known as x64, AMD64 and Intel 64. For ARM, which has been supported since version 0.7.0, there are the 32-bit CPUs, ARM32 or AArch32, and the 64-bit CPUs, ARM64 or AArch64.

Two properties from the README are worth carrying into any evaluation. The library requires no dependencies on any of the supported operating systems, which is a strong statement for a C library and is what makes it comfortable to vendor into something that has to build in a constrained environment. And the repository layout shows a project with a long history rather than a recent arrival: an autotools build with configure.ac and Makefile.am, a CMake build, a pkg-config template at libcpuid.pc.in, Visual Studio solutions going back to libcpuid_vc10.sln and libcpuid_vc71.sln, a python directory, a utils directory, a tests directory and a dedicated drivers directory.

The support matrix, and what a question mark means

The most valuable thing in the README is the table of operating system support, and the reason it exists is that there are two different things a library like this needs: the ability to build, and the ability to read the privileged registers that hold the information.

The columns are Build, x86 MSR and ARM CPUID. The MSR route is the x86 model specific register path, and on Linux it needs the msr kernel module, on FreeBSD and DragonFly the cpuctl kernel module, and on Windows the bundled msr driver. The ARM route is the CPUID instruction, and on Linux and FreeBSD it needs the cpuid out-of-tree kernel module, which the repository carries under drivers/arm.

Now the results. Linux supports all three: it builds, it has the x86 MSR access through the msr module, and it has the ARM CPUID access. FreeBSD is the same, with the cpuctl module and the out-of-tree cpuid module. Windows builds and has x86 MSR access through the bundled driver, but no ARM CPUID. DragonFly BSD builds, and its x86 MSR support is marked with a question mark, which the legend defines as likely supported but not heavily tested. macOS, NetBSD and OpenBSD all build, and both of their register access columns are marked with a cross, meaning not supported.

That last grouping is the one to internalise. On macOS, where the platform already provides CPU identification through its own interfaces, libcpuid builds and the parts that do not require privileged access work, but the register access does not. So the library is not equally capable everywhere, and a feature that works on a Linux server may be absent on the same code running on a laptop.

The footnote on the ARM column is a nice piece of detail. On AArch32 state the kernel module is required, while on AArch64 state it is optional, because the kernel can trap the MRS instruction that reads the system register. In other words, on 64-bit ARM the operating system can mediate the access on your behalf, while on 32-bit ARM it cannot, and you need the module to get there.

Building it: two build systems and a set of documented options

There are two ways to get the library: build it from sources, or download a pre-compiled binary. The README notes that versioned archives with binaries for macOS and Windows are on the releases page.

Building needs the usual build tools, automake, autoconf, libtool and cmake, and a POSIX-compatible shell. The NetBSD case is spelled out because it is the exception: install a shell such as ksh93, with pkg_add ast-ksh or pkgin in ast-ksh, and export CONFIG_SHELL with the correct path if required.

The autotools route is three commands after checkout. There is no configure script in the repository, because the README says keeping such scripts in a source control system is not a good practice, so you generate it:

libtoolize
autoreconf --install

After that you can run ./configure and make, and make dist will create a tarball with the configure script inside it.

The CMake route is the recommended one for new work, and the options are documented in the README, with cmake -LH to list them all. LIBCPUID_ENABLE_DOCS turns on documentation building with Doxygen and is on by default. LIBCPUID_ENABLE_TESTS enables the test targets, named test-fast, test-old and fix-tests, and is off by default. LIBCPUID_BUILD_DEPRECATED builds support for deprecated attributes and is on by default to guarantee backward compatibility. LIBCPUID_BUILD_DRIVERS builds the kernel drivers and is on by default, LIBCPUID_DRIVER_DEBUG is off, and LIBCPUID_DRIVER_ARM_LINUX_DKMS uses DKMS for the ARM CPUID Linux kernel module and is on by default, with the alternative being to build the module in the build directory.

The three command example the README gives is:

cmake -S . -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo -DLIBCPUID_ENABLE_TESTS=ON
cmake --build build
cmake --install build # may need administrative privileges, install under /usr/local by default

Two of those options are policy decisions in disguise. Building the deprecated attributes by default is a compatibility choice that keeps older callers working at the cost of carrying code forward. And turning the tests off by default means a distribution that just wants the library will not build them, so the option has to be set deliberately if you want the test-fast, test-old and fix-tests targets available.

Installing it: a cpuidtool and the distributions that ship it

The library is packaged in a long list of distributions, and the README lists the package names and the first version that carried it.

Arch Linux carries it as pacman -S libcpuid. Debian has carried it since version 11, Bullseye, as apt install cpuidtool libcpuid-dev. Fedora has it since version 25, as dnf install libcpuid libcpuid-devel. FreeBSD has had it since version 11, as pkg install libcpuid. OpenMandriva Lx has carried it since version 4.0, Nitrogen, openSUSE Leap since version 15.1, Solus as eopkg install libcpuid libcpuid-devel, and Ubuntu since version 20.04, Focal Fossa, again as apt install cpuidtool libcpuid-dev. There is also a Vcpkg build tool entry, vcpkg install cpuid, and a Repology badge for the full picture.

Two observations follow from that list.

The first is that the package names vary by convention, and in two of them the tool and the development files are separate packages. On Debian and Ubuntu you get cpuidtool and libcpuid-dev, which is the split between the command line program and the headers and library. On Fedora and openSUSE the split is libcpuid and libcpuid-devel, with a -tools package name on openSUSE. That is packaging convention rather than a design decision, but it matters when you write an installation script.

The second is the age of the entries. Debian Bullseye is from 2020, Ubuntu Focal is from 2020, FreeBSD 11 is from 2016, and Fedora 25 is from 2016. So the library has been in the mainstream distributions for long enough that your build system's package is likely to be old. Whether the packaged version has the ARM support that arrived in version 0.7.0 is a question to check against your distribution's version rather than assume.

The cpuidtool is the command line companion, and the usage section of the README starts with the native C library, with the tool and the Python bindings following further down.

Licence, releases and the shape of the tree

The licence situation needs a note. The platform metadata records the licence as Other, a custom one it cannot categorise, and the repository root holds a COPYING file, which is the file to read. The README does not summarise the terms, so if you are vendoring this into a product, the COPYING file is where the answer is.

The release history is short and current. The tags are v0.8.2 from 2026-09-13, v0.8.1 from 2025-08-19 and v0.8.0 from 2025-05-04, and the last push to the repository was on the same day as the newest tag, 2026-09-13. So the project is on a 0.x line that still moves, with roughly one release a year, the newest being from September 2026.

The directory layout shows a mature C project with a broad build surface. The libcpuid directory holds the library itself, cpuid_tool the command line program, drivers the kernel modules, including the x86 Windows msr driver and the ARM CPUID modules for Linux and FreeBSD, tests the test suite, python the Python bindings, utils the utilities, and cmake the CMake modules. The build metadata is duplicated deliberately, with configure.ac and Makefile.am for autotools alongside CMakeLists.txt and a cmake-format.py for formatting the CMake files.

There are also two Visual Studio solutions, libcpuid_vc10.sln and libcpuid_vc71.sln, and a libcpuid.dsw, which is the Visual Studio workspace format. That set of files is a small archive of the project's history, and it is also the reason there is a.readthedocs.yml in the root, since the documentation is built with a hosted tool.

For an adopter, the practical takeaway is that this is a library with stable packaging, a long history of distribution support and a small, understandable code base, and that the two questions worth asking before you build on it are whether your target platform gives you register access at all, and how old the version in your distribution is.

Editorial conclusion

Adopt libcpuid if you need to identify a processor at runtime, detect which instruction set extensions it supports, or read vendor specific registers, and you want a dependency free C library with a long history of shipping in distributions. Do not adopt it if you only need a feature bit for a single instruction set, since the operating system interfaces that expose those bits are usually enough, and do not assume it works everywhere, because the README's matrix shows macOS, NetBSD and OpenBSD with no model specific register access at all. Verify first which of the two access paths your target platform supports, the x86 MSR route on Linux, FreeBSD, DragonFly and Windows, or the ARM CPUID route on Linux and FreeBSD, that your kernel module is loaded if you need privileged access on Linux, where the msr and cpuid modules are required, and that the licence in the COPYING file is the one you expect, since the platform classifies it as a custom licence rather than one of the standard identifiers.

Frequently asked questions

Official sources

1. anrieff/libcpuid on GitHub
2. Issues
3. README
4. Releases