OpenBLAS's install step makes you repeat your build flags

master still exists, and it is far out of date

The installation section says where to get the source and then warns you about the branch. The default branch is develop, and a master branch is still present but far out of date.

That is unusual enough to repeat, because for most projects the default branch is what everyone assumes. Here, cloning the default gets you the current line, and the other branch is a historical artifact rather than a fallback.

The release history supports that reading. The three most recent tags are all 0.3.x, from March, April and July 2026, and the last push to the default branch is dated 2 November 2026.

So if you are packaging this or vendoring it, the branch name is a decision rather than a detail, and the readme tells you which one to take.

The install step needs the options you gave the build

The normal compile is one command. Invoking make, or its BSD equivalent, detects the CPU automatically, and a specific target can be requested with a target option.

make TARGET=NEHALEM

Then comes the instruction that costs people an afternoon. When you run make install after building, you need to repeat all the command line options you gave to make in the build step.

The reason given is specific: some settings, such as the supported maximum number of threads, are automatically derived from the build host by default, and that might not be what you want. So the library would otherwise be compiled with a thread ceiling based on the machine that built it rather than the machine that runs it.

The default install location is a directory under the opt prefix, and it can be changed with a prefix option, provided you also pass the options from the build step again.

One Makefile per instruction set, and a shared rule file

The repository root is a wall of makefiles, and the naming is the explanation. There is one per architecture: alpha, arm, arm64, csky, e2k, ia64, loongarch64, mips, mips64, power, riscv64, sparc, x86, x86_64 and zarch, plus a wasm one. Alongside them are makefiles with roles rather than architectures, including the rule file that documents every build option, a system file for host detection, an install file, a prebuild file, a tail file and a generic one.

That is twenty-odd files, and it is the price of a library that has to hand-tune compiler flags per instruction set. The payoff is the target list file, which the readme points to as the authoritative list of what can be built.

Build options can be set in two ways: uncommenting a line in the rule file, or passing them on the command line. The readme documents both, and notes that most options work as parameters to either make or cmake.

So the build system is old-fashioned on purpose.

DYNAMIC_ARCH decides whether a kernel library is built

The main makefile is short enough to read as a description of the build. It includes the system file, sets up a symbolic link command, and assembles a list of directories to build.

The list of BLAS directories is fixed: an interface directory, two driver levels and a directory of others. Then two conditionals change it. If dynamic architecture is not enabled, a kernel directory is added. And if a sanity check is defined, a reference directory is added as well.

Separately, the readme notes that when compiling for a more modern CPU target of the same architecture, such as a newer target on an older host, the CROSS=1 option can suppress the automatic invocation of tests at the end of the build.

Without Fortran you get an older translated LAPACK

LAPACK, the higher-level library, comes included with OpenBLAS. Its dependency is a Fortran compiler, listed as optional because there is a fallback.

If a Fortran compiler is not available, it is possible to compile an older version of the included LAPACK that has been machine-translated to C. Using a recent version of the compiler is strongly recommended, which is the readme's way of saying the fallback is a compromise.

The makefile implements this as two internal variables. When NO_FORTRAN is set, the build defines a no-Fortran flag, and if LAPACK is still wanted it defines a second flag selecting the C version. There is also logic that strips optimisation flags out of the Fortran flags, with a separate branch for one particular compiler family.

So the Fortran dependency is not just a package you install. It selects which implementation of a whole library you get, and the default install step must be told the same thing as the build.

Cross compiling sets three compilers and an explicit target

Cross compilation is documented with two complete examples, and both set the same three variables.

You point the C compiler and the Fortran compiler at the cross toolchains, and if you are using make you also set a host compiler variable so the build tools themselves are built for the host. The target must be specified explicitly, which is the opposite of the automatic detection you get for a native build.

One example cross compiles from Linux to an older 64-bit MIPS router board, giving the architecture, both cross compilers, the host compiler and a specific target. The other targets a Windows host with a mingw toolchain and adds several of the tuning options at once, including a thread count and a flag for consistent floating point state.

The readme also points at the yml scripts shipped with the sources, which contain the build recipes used by continuous integration, as an additional source of examples. That is a good tip for anyone cross compiling to a combination nobody has written down.

Binary packages exist for Windows, and only Windows

The binary packages section is short and the omission is the point. Official binaries are provided for Windows on both 32-bit and 64-bit x86, and for Windows on arm64. Nowhere else.

Those can be downloaded from a file hosting site or from the releases section of the project page. The readme then says OpenBLAS is also packaged for many package managers and points at the installation section of the documentation for details.

So on Linux and macOS, the package manager is the intended route rather than the official binary. The readme is careful not to claim those packages are current, which is the appropriate hedge given how this project versions itself.

The GotoBLAS documentation kept its numbered prefixes

Seven text files at the repository root carry a numerical prefix and a topic: the licence readme, the main readme, a quick install guide, two FAQ files, one on large pages and one titled about weird performance.

These are inherited from GotoBLAS, and keeping the prefix is a deliberate way of preserving provenance. The readme also points at the main readme file for supported processors and systems, which means the authoritative list of what this library can target is a document that predates the project.

Alongside them sit files that are clearly current: a changelog, a contributors file, a backers file, a security policy, a usage guide, a target list, the C interface header and a per-architecture common header for each of the targets.

The root therefore contains two eras of documentation side by side, and the readme's instruction to consult the older one for supported systems is the only guide to which is which.

Editorial conclusion

OpenBLAS fits a numerical project that needs a tuned BLAS and LAPACK and is willing to build it for its own processor, especially one cross-compiling to unusual hardware. Before building, note the branch you are on, keep your build options in a file because the install step needs them again, and check whether the architecture you want is in the target list.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. OpenMathLib/OpenBLAS on GitHub
3. Project website
4. README
5. Releases