# 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). ```cplus 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--x64.zip`) ships `lib/libopenblas.lib` and `bin/libopenblas.dll`, so set `OPENBLAS_LIB=\lib` and `OPENBLAS_NAME=libopenblas`, and put `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.