openblas-src

openblas-src is a Cargo “sys crate” that gives Rust programs access to BLAS and LAPACK by building or linking OpenBLAS. Rather than reimplementing linear algebra routines, it handles the mechanics of getting a working OpenBLAS binary in place: downloading and compiling the upstream OpenBLAS C/Fortran sources during cargo build, or detecting an already-installed OpenBLAS via pkg-config, Homebrew, or vcpkg depending on platform.

The crate is split into two workspace members: openblas-src, the thin public-facing crate that downstream projects depend on, and openblas-build, an internal helper crate that drives the actual OpenBLAS make-based build, downloads the pinned OpenBLAS release tarball over HTTPS, and inspects build artifacts. Cargo features (system, static, cache, cblas, lapacke, rustls/native-tls) select between vendored and system builds, static and dynamic linking, and shared build-artifact caching across projects.

Because it declares links = "openblas" and exports DEP_OPENBLAS_INCLUDE/DEP_OPENBLAS_LIBRARY environment variables, openblas-src is designed to sit underneath higher-level crates (BLAS/LAPACK Rust bindings, ndarray-linalg-style numerical crates) rather than being used directly by application code.

What You Get

• A cargo build-time pipeline that downloads a pinned OpenBLAS release tarball and compiles it via make, with no manual toolchain setup beyond a C/Fortran compiler
• A system feature that instead locates an existing OpenBLAS install through pkg-config (Linux), Homebrew paths (macOS), or vcpkg (Windows)
• Feature flags to control what gets built: cblas and lapacke for the C wrapper APIs, static for static linking, cache to reuse build artifacts across projects via a hashed directory under the user’s data dir
• DEP_OPENBLAS_INCLUDE and DEP_OPENBLAS_LIBRARY environment variables exported for downstream build scripts to consume
• Cross-compilation support through OPENBLAS_TARGET/OPENBLAS_CC/OPENBLAS_FC/OPENBLAS_HOSTCC environment variables, with automatic Rust-target-to-OpenBLAS-target mapping for common architectures

Common Use Cases

• Providing the BLAS/LAPACK backend for scientific-computing crates like ndarray-linalg or other linear-algebra bindings that need real symbols to link against
• Building numerical Rust binaries in CI or Docker without pre-installing OpenBLAS, by letting the crate vendor-build it from source
• Linking against a distro- or Homebrew-managed OpenBLAS in environments where a system package is already the preferred install path
• Cross-compiling numerical Rust code to non-native architectures by setting the OPENBLAS_TARGET/OPENBLAS_CC family of environment variables

Under The Hood

Architecture The project is a two-crate Cargo workspace: openblas-src, a #![no_std] public crate whose lib.rs does nothing but embed the README as documentation, and openblas-build, an internal build-helper crate (build.rs, check.rs, download.rs, error.rs) that openblas-src’s own build.rs depends on. At build time, openblas-src/build.rs branches on the system feature: with it set, it probes for OpenBLAS via pkg-config, then platform-specific fallbacks (windows_gnu_system, windows_msvc_system via vcpkg, macos_system via brew --prefix); without it, it calls into openblas_build::download to fetch a pinned OpenBLAS release tarball and Configure::build to drive OpenBLAS’s own make-based build system, then emits cargo:rustc-link-search/cargo:rustc-link-lib directives. The crate’s real “product” is this build-time orchestration and the DEP_OPENBLAS_INCLUDE/DEP_OPENBLAS_LIBRARY env vars it exposes to downstream build scripts, not any runtime Rust code — a change to that build.rs/openblas-build boundary breaks linking for every dependent crate.

Tech Stack Rust workspace on edition 2018, rust-version = "1.71.1". openblas-src’s build-dependencies are pkg-config 0.3.30, dirs 6.0.0, and (Windows only) vcpkg 0.2, plus a path dependency on openblas-build. openblas-build itself depends on anyhow, cc, flate2 and tar (to unpack the downloaded release), thiserror 2.0 for typed errors, and ureq 3.0 (gated behind rustls or native-tls features) to download the OpenBLAS tarball over HTTPS without a full TLS stack dependency; libc is a dev-dependency used only by the FFI smoke tests. The actual OpenBLAS build is driven through GNU make and a C/Fortran toolchain (gcc/clang/icc, gfortran/flang/ifort), invoked as an external process from openblas-build. CI runs on GitHub Actions with a Windows-MSVC matrix across vcpkg linking triplets and separate workflows scoped to each crate’s changed paths.

Code Quality Testing is deliberately thin on unit tests but concrete at the integration level: openblas-src/tests/lib.rs and fortran_lapack.rs link against the built OpenBLAS and call real BLAS/LAPACK FFI symbols (e.g. srotg_) to assert the linked library actually computes correctly, which is the meaningful correctness surface for a sys crate. openblas-build has its own cargo test suite plus CI-only --ignored build tests (build_no_lapacke, build_no_shared, build_openmp) that exercise real compiler toolchains. Error handling in openblas-build uses typed errors via thiserror and anyhow, while openblas-src’s build.rs uses panic! for unrecoverable build failures, which is idiomatic for a Cargo build script. No linter/formatter config beyond Rust defaults is visible, and there’s no explicit clippy step in CI — the emphasis is squarely on cross-platform build-matrix coverage over static analysis.

What Makes It Unique The crate’s distinguishing choice is unifying two very different linking strategies — vendor-building OpenBLAS from a pinned source release with a pure-Rust HTTPS downloader, or detecting a system install via pkg-config/Homebrew/vcpkg — behind one consistent Cargo feature surface, so downstream numerical crates don’t have to care which path a given environment takes. The cache feature, which shares built OpenBLAS artifacts across projects in a config-hashed directory under the user’s XDG data dir, is a pragmatic answer to the expensive-rebuild problem that most sys crates leave unsolved. These are still standard sys-crate engineering patterns rather than a novel technical approach; the value is in polish and platform coverage, not invention.