cblas

C+ bindings for the CBLAS interface (cblas.h), as OpenBLAS provides it, generated by cpc-bindgen --cpackage (see Cplus.toml for the reproduce lines). The modules are generated: never edit them; regenerate. The CPU fallback the GPU guide names (docs/GPU.md).

import "cblas/cblas" as blas;

var x: [f64; 3] = [1.0f64, 2.0f64, 3.0f64];
var y: [f64; 3] = [4.0f64, 5.0f64, 6.0f64];
let d: f64 = blas::cblas_ddot(3, #addr_of(x) as *f64, 1, #addr_of(y) as *f64, 1);   // 32

Linking

[link] is libs = ["${OPENBLAS_NAME:-openblas}"] and search-paths = ["${OPENBLAS_LIB:-/usr/lib/x86_64-linux-gnu/openblas-pthread/}"]:

• Linux (Debian/Ubuntu libopenblas-dev): nothing to set.
• Elsewhere: OPENBLAS_LIB = the directory holding the library.
• Windows: OpenBLAS's release zip (OpenBLAS-<v>-x64.zip) ships lib/libopenblas.lib and bin/libopenblas.dll, so set OPENBLAS_LIB=<root>\lib and OPENBLAS_NAME=libopenblas, and put <root>in on PATH (or the DLL beside the executable) at run time - a PE image has no rpath.

Windows module

src/cblas_windows.cplus shadows cblas.cplus on Windows. The shared module comes from Debian's header and the Windows release does not export every function it declares - the bfloat16 and half-precision routines (cblas_sb*, cblas_sh*, cblas_b*), the strided-batch GEMMs and openblas_set_num_threads_local - so a Windows program importing it did not link. The Windows module is generated from the release's own include/cblas.h with those 17 skipped: the list is every bound symbol missing from llvm-nm lib/libopenblas.lib. Verified with OpenBLAS 0.3.34 (x64): a cblas_ddot program links and answers 32.

cpc test here computes a dot product (src/test_main.cplus). A test build compiles away wrappers nothing calls, so it does not prove the Windows module binds only exported symbols: build an application after regenerating.