Install OpenBLAS

OpenBLAS can be installed through package managers or from source. If you only want to use OpenBLAS rather than make changes to it, we recommend installing a pre-built binary package with your package manager of choice.

This page contains an overview of installing with package managers as well as from source. For the latter, see further down on this page.

Installing with a package manager

Note

Almost every package manager provides OpenBLAS packages; the list on this page is not comprehensive. If your package manager of choice isn't shown here, please search its package database for openblas or libopenblas.

Linux

On Linux, OpenBLAS can be installed with the system package manager, or with a package manager like Conda (or alternative package managers for the conda-forge ecosystem, like Mamba, Micromamba, or Pixi), Spack, or Nix. For the latter set of tools, the package name in all cases is openblas. Since package management in quite a few of these tools is declarative (i.e., managed by adding openblas to a metadata file describing the dependencies for your project or environment), we won't attempt to give detailed instructions for these tools here.

Linux distributions typically split OpenBLAS up in two packages: one containing the library itself (typically named openblas or libopenblas), and one containing headers, pkg-config and CMake files (typically named the same as the package for the library with -dev or -devel appended; e.g., openblas-devel). Please keep in mind that if you want to install OpenBLAS in order to use it directly in your own project, you will need to install both of those packages.

Distro-specific installation commands:

Debian/Ubuntu/Mint/KaliopenSUSE/SLEFedora/CentOS/RHELArch/Manjaro/Antergos

$ sudo apt update
$ sudo apt install libopenblas-dev

OpenBLAS can be configured as the default BLAS through the update-alternatives mechanism:

$ sudo update-alternatives --config libblas.so.3

$ sudo zypper refresh
$ sudo zypper install openblas-devel

OpenBLAS can be configured as the default BLAS through the update-alternatives mechanism:

$ sudo update-alternatives --config libblas.so.3

$ dnf check-update
$ dnf install openblas-devel

Warning

Fedora does not ship the pkg-config files for OpenBLAS. Instead, it wants you to link against FlexiBLAS (which uses OpenBLAS by default as its backend on Fedora), which you can install with:

$ dnf install flexiblas-devel

For CentOS and RHEL, OpenBLAS packages are provided via the Fedora EPEL repository. After adding that repository and its repository keys, you can install openblas-devel with either dnf or yum.

$ sudo pacman -S openblas

Windows

Conda-forgevcpkgOpenBLAS releases

OpenBLAS can be installed with conda (or mamba, micromamba, or pixi) from conda-forge:

conda install openblas

Conda-forge provides a method for switching the default BLAS implementation used by all packages. To use that for OpenBLAS, install libblas=*=*openblas (see the docs on this mechanism for more details).

OpenBLAS can be installed with vcpkg:

# In classic mode:
vcpkg install openblas

# Or in manifest mode:
vcpkg add port openblas

Windows is the only platform for which binaries are made available by the OpenBLAS project itself. They can be downloaded from the GitHub Releases](https://github.com/OpenMathLib/OpenBLAS/releases) page. These binaries are built with MinGW, using the following build options:

NUM_THREADS=64 TARGET=GENERIC DYNAMIC_ARCH=1 DYNAMIC_OLDER=1 CONSISTENT_FPCSR=1 INTERFACE=0

There are separate packages for x86-64 and x86. The zip archive contains the include files, static and shared libraries, as well as configuration files for getting them found via CMake or pkg-config. To use these binaries, create a suitable folder for your OpenBLAS installation and unzip the .zip bundle there (note that you will need to edit the provided openblas.pc and OpenBLASConfig.cmake to reflect the installation path on your computer, as distributed they have "win" or "win64" reflecting the local paths on the system they were built on).

Note that the same binaries can be downloaded from SourceForge; this is mostly of historical interest.

macOS

To install OpenBLAS with a package manager on macOS, run:

HomebrewMacPortsConda-forge

% brew install openblas

% sudo port install OpenBLAS-devel

% conda install openblas

Conda-forge provides a method for switching the default BLAS implementation used by all packages. To use that for OpenBLAS, install libblas=*=*openblas (see the docs on this mechanism for more details).

FreeBSD

You can install OpenBLAS from the FreeBSD Ports collection:

pkg install openblas

Building from source

We recommend download the latest stable version from the GitHub Releases page, or checking it out from a git tag, rather than a dev version from the develop branch.

Tip

The User manual contains a section with detailed information on compiling OpenBLAS, including how to customize builds and how to cross-compile. Please read that documentation first. This page contains only platform-specific build information, and assumes you already understand the general build system invocations to build OpenBLAS, with the specific build options you want to control multi-threading and other non-platform-specific behavior).

Linux and macOS

Ensure you have C and Fortran compilers installed, then simply type make to compile the library. There are no other build dependencies, nor unusual platform-specific environment variables to set or other system setup to do.

Note

When building in an emulator (KVM, QEMU, etc.), please make sure that the combination of CPU features exposed to the virtual environment matches that of an existing CPU to allow detection of the CPU model to succeed. (With qemu, this can be done by passing -cpu host or a supported model name at invocation).

Windows

We support building OpenBLAS with either MinGW or Visual Studio on Windows. Using MSVC will yield an OpenBLAS build with the Windows platform-native ABI. Using MinGW will yield a different ABI. We'll describe both methods in detail in this section, since the process for each is quite different.

Visual Studio & native Windows ABI

For Visual Studio, you can use CMake to generate Visual Studio solution files; note that you will need at least CMake 3.11 for linking to work correctly).

Note that you need a Fortran compiler if you plan to build and use the LAPACK functions included with OpenBLAS. The sections below describe using either flang as an add-on to clang/LLVM or gfortran as part of MinGW for this purpose. If you want to use the Intel Fortran compiler (ifort or ifx) for this, be sure to also use the Intel C compiler (icc or icx) for building the C parts, as the ABI imposed by ifort is incompatible with MSVC

A fully-optimized OpenBLAS that can be statically or dynamically linked to your application can currently be built for the 64-bit architecture with the LLVM compiler infrastructure. We're going to use Miniconda3 to grab all of the tools we need, since some of them are in an experimental status. Before you begin, you'll need to have Microsoft Visual Studio 2015 or newer installed.

Install Miniconda3 for 64-bit Windows using winget install --id Anaconda.Miniconda3, or easily download from conda.io.
Open the "Anaconda Command Prompt" now available in the Start Menu, or at %USERPROFILE%\miniconda3\shell\condabin\conda-hook.ps1.
In that command prompt window, use cd to change to the directory where you want to build OpenBLAS.

Now install all of the tools we need:

conda update -n base conda
conda config --add channels conda-forge
conda install -y cmake flang clangdev perl libflang ninja

Still in the Anaconda Command Prompt window, activate the 64-bit MSVC environment with vcvarsall x64. On Windows 11 with Visual Studio 2022, this would be done by invoking:
```
"c:\Program Files\Microsoft Visual Studio\2022\Community\vc\Auxiliary\Build\vcvars64.bat"
```
With VS2019, the command should be the same (except for the year number of course). For other versions of MSVC, please check the Visual Studio documentation for exactly how to invoke the vcvars64.bat script.

Confirm that the environment is active by typing link. This should return a long list of possible options for the link command. If it just returns "command not found" or similar, review and retype the call to vcvars64.bat.

Note

if you are working from a Visual Studio command prompt window instead (so that you do not have to do the vcvars call), you need to invoke conda activate so that CONDA_PREFIX etc. get set up correctly before proceeding to step 6. Failing to do so will lead to link errors like libflangmain.lib not getting found later in the build.
Now configure the project with CMake. Starting in the project directory, execute the following:
```
set "LIB=%CONDA_PREFIX%\Library\lib;%LIB%"
set "CPATH=%CONDA_PREFIX%\Library\include;%CPATH%"
mkdir build
cd build
cmake .. -G "Ninja" -DCMAKE_CXX_COMPILER=clang-cl -DCMAKE_C_COMPILER=clang-cl -DCMAKE_Fortran_COMPILER=flang -DCMAKE_MT=mt -DBUILD_WITHOUT_LAPACK=no -DNOFORTRAN=0 -DDYNAMIC_ARCH=ON -DCMAKE_BUILD_TYPE=Release
```
You may want to add further options in the cmake command here. For instance, the default only produces a static .lib version of the library. If you would rather have a DLL, add -DBUILD_SHARED_LIBS=ON above. Note that this step only creates some command files and directories, the actual build happens next.
Build the project:
```
cmake --build . --config Release
```
This step will create the OpenBLAS library in the lib directory, and various build-time tests in the test, ctest and openblas_utest directories. However it will not separate the header files you might need for building your own programs from those used internally. To put all relevant files in a more convenient arrangement, run the next step.
Install all relevant files created by the build:
```
cmake --install . --prefix c:\opt -v
```
This will copy all files that are needed for building and running your own programs with OpenBLAS to the given location, creating appropriate subdirectories for the individual kinds of files. In the case of C:\opt as given above, this would be:
- C:\opt\include\openblas for the header files,
- C:\opt\bin for the libopenblas.dll shared library,
- C:\opt\lib for the static library, and
- C:\opt\share holds various support files that enable other cmake-based build scripts to find OpenBLAS automatically.

Change in complex types for Visual Studio 2017 and up

In newer Visual Studio versions, Microsoft has changed how it handles complex types. Even when using a precompiled version of OpenBLAS, you might need to define LAPACK_COMPLEX_CUSTOM in order to define complex types properly for MSVC. For example, some variant of the following might help:

#if defined(_MSC_VER)
    #include <complex.h>
    #define LAPACK_COMPLEX_CUSTOM
    #define lapack_complex_float _Fcomplex
    #define lapack_complex_double _Dcomplex
#endif

For reference, see openblas#3661, lapack#683, and this Stack Overflow question.

Building 32-bit binaries with MSVC

This method may produce binaries which demonstrate significantly lower performance than those built with the other methods. The Visual Studio compiler does not support the dialect of assembly used in the cpu-specific optimized files, so only the "generic" TARGET which is written in pure C will get built. For the same reason it is not possible (and not necessary) to use -DDYNAMIC_ARCH=ON in a Visual Studio build. You may consider building for the 32-bit architecture using the GNU (MinGW) ABI instead.

CMake & Visual Studio integration

To generate Visual Studio solution files, ensure CMake is installed and then run:

# Do this from Powershell so cmake can find visual studio
cmake -G "Visual Studio 14 Win64" -DCMAKE_BUILD_TYPE=Release .

To then build OpenBLAS using those solution files from within Visual Studio, we also need Perl. Please install it and ensure it's on the PATH (see, e.g., this Stack Overflow question for how).

If you build from within Visual Studio, the dependencies may not be automatically configured: if you try to build libopenblas directly, it may fail with a message saying that some .obj files aren't found. If this happens, you can work around the problem by building the projects that libopenblas depends on before building libopenblas itself.

Build OpenBLAS for Universal Windows Platform

OpenBLAS can be built targeting Universal Windows Platform (UWP) like this:

Follow the steps above to build the Visual Studio solution files for Windows. This builds the helper executables which are required when building the OpenBLAS Visual Studio solution files for UWP in step 2.

Remove the generated CMakeCache.txt and the CMakeFiles directory from the OpenBLAS source directory, then re-run CMake with the following options:

# do this to build UWP compatible solution files
cmake -G "Visual Studio 14 Win64" -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION="10.0" -DCMAKE_SYSTEM_PROCESSOR=AMD64 -DVS_WINRT_COMPONENT=TRUE -DCMAKE_BUILD_TYPE=Release .

3. Now build the solution with Visual Studio.

MinGW & GNU ABI

Note

The resulting library from building with MinGW as described below can be used in Visual Studio, but it can only be linked dynamically. This configuration has not been thoroughly tested and should be considered experimental.

To build OpenBLAS on Windows with MinGW:

Install the MinGW (GCC) compiler suite, either the 32-bit [MinGW]((http://www.mingw.org/) or the 64-bit MinGW-w64 toolchain. Be sure to install its gfortran package as well (unless you really want to build the BLAS part of OpenBLAS only) and check that gcc and gfortran are the same version. In addition, please install MSYS2 with MinGW.
Build OpenBLAS in the MSYS2 shell. Usually, you can just type make. OpenBLAS will detect the compiler and CPU automatically.
After the build is complete, OpenBLAS will generate the static library libopenblas.a and the shared library libopenblas.dll in the folder. You can type make PREFIX=/your/installation/path install to install the library to a certain location.

Note that OpenBLAS will generate the import library libopenblas.dll.a for libopenblas.dll by default.

If you want to generate Windows-native PDB files from a MinGW build, you can use the cv2pdb tool to do so.

To then use the built OpenBLAS shared library in Visual Studio:

Copy the import library (OPENBLAS_TOP_DIR/libopenblas.dll.a) and the shared library (libopenblas.dll) into the same folder (this must be the folder of your project that is going to use the BLAS library. You may need to add libopenblas.dll.a to the linker input list: properties->Linker->Input).
Please follow the Visual Studio documentation about using third-party .dll libraries, and make sure to link against a library for the correct architecture.¹
If you need CBLAS, you should include cblas.h in /your/installation/path/include in Visual Studio. Please see openblas#95 for more details.

Limitations of using the MinGW build within Visual Studio

Both static and dynamic linking are supported with MinGW. With Visual Studio, however, only dynamic linking is supported and so you should use the import library.
Debugging from Visual Studio does not work because MinGW and Visual Studio have incompatible formats for debug information (PDB vs. DWARF/STABS). You should either debug with GDB on the command line or with a visual frontend, for instance Eclipse or Qt Creator.

Windows on Arm

While OpenBLAS can be built with Microsoft VisualStudio (Community Edition or commercial), you would only be able to build for the GENERIC target that does not use optimized assembly kernels, also the stock VisualStudio lacks the Fortran compiler necessary for building the LAPACK component. It is therefore highly recommended to download the free LLVM compiler suite and use it to compile OpenBLAS outside of VisualStudio.

The following tools needs to be installed to build for Windows on Arm (WoA):

LLVM for Windows on Arm. Find the latest LLVM build for WoA from LLVM release page - you want the package whose name ends in "woa64.exe". (This may not always be present in the very latest point release, as building and uploading the binaries takes time.) E.g: a LLVM 19 build for WoA64 can be found here. Run the LLVM installer and ensure that LLVM is added to the environment variable PATH. (If you do not want to add it to the PATH, you will need to specify both C and Fortran compiler to Make or CMake with their full path later on)

The following steps describe how to build the static library for OpenBLAS with either Make or CMake:

Build OpenBLAS with Make:

$ make CC=clang-cl FC=flang-new AR="llvm-ar" TARGET=ARMV8 ARCH=arm64 RANLIB="llvm-ranlib" MAKE=make

Build OpenBLAS with CMake

$ mkdir build
$ cd build
$ cmake .. -G Ninja -DCMAKE_C_COMPILER=clang-cl -DCMAKE_Fortran_COMPILER=flang-new -DTARGET=ARMV8 -DCMAKE_BUILD_TYPE=Release
$ cmake --build .

Generating an import library

Microsoft Windows has this thing called "import libraries". You need it for MSVC; you don't need it for MinGW because the ld linker is smart enough - however, you may still want it for some reason, so we'll describe the process for both MSVC and MinGW.

Import libraries are compiled from a list of what symbols to use, which are contained in a .def file. A .def file should be already be present in the exports directory under the top-level OpenBLAS directory after you've run a build. In your shell, move to this directory: cd exports.

MSVCMinGW

Unlike MinGW, MSVC absolutely requires an import library. Now the C ABI of MSVC and MinGW are actually identical, so linking is actually okay (any incompatibility in the C ABI would be a bug).

The import libraries of MSVC have the suffix .lib. They are generated from a .def file using MSVC's lib.exe. See the MSVC instructions.

MinGW import libraries have the suffix .a, just like static libraries. Our goal is to produce the file libopenblas.dll.a.

You need to first insert a line LIBRARY libopenblas.dll in libopenblas.def:

cat <(echo "LIBRARY libopenblas.dll") libopenblas.def > libopenblas.def.1
mv libopenblas.def.1 libopenblas.def

Now the .def file probably looks like:

LIBRARY libopenblas.dll
EXPORTS
   caxpy=caxpy_  @1
   caxpy_=caxpy_  @2
       ...

Then, generate the import library: dlltool -d libopenblas.def -l libopenblas.dll.a

Again, there is basically no point in making an import library for use in MinGW. It actually slows down linking.

Android

To build OpenBLAS for Android, you will need the following tools installed on your machine:

The Android NDK
Perl
Clang compiler on the build machine

The next two sections below describe how to build with Clang for ARMV7 and ARMV8 targets, respectively. The same basic principles as described below for ARMV8 should also apply to building an x86 or x86-64 version (substitute something like NEHALEM for the target instead of ARMV8, and replace all the aarch64 in the toolchain paths with x86 or x96_64 as appropriate).

Historic note

Since NDK version 19, the default toolchain is provided as a standalone toolchain, so building one yourself following building a standalone toolchain should no longer be necessary.

Building for ARMV7

# Set path to ndk-bundle
export NDK_BUNDLE_DIR=/path/to/ndk-bundle

# Set the PATH to contain paths to clang and arm-linux-androideabi-* utilities
export PATH=${NDK_BUNDLE_DIR}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin:${NDK_BUNDLE_DIR}/toolchains/llvm/prebuilt/linux-x86_64/bin:$PATH

# Set LDFLAGS so that the linker finds the appropriate libgcc
export LDFLAGS="-L${NDK_BUNDLE_DIR}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x"

# Set the clang cross compile flags
export CLANG_FLAGS="-target arm-linux-androideabi -marm -mfpu=vfp -mfloat-abi=softfp --sysroot ${NDK_BUNDLE_DIR}/platforms/android-23/arch-arm -gcc-toolchain ${NDK_BUNDLE_DIR}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/"

#OpenBLAS Compile
make TARGET=ARMV7 ONLY_CBLAS=1 AR=ar CC="clang ${CLANG_FLAGS}" HOSTCC=gcc ARM_SOFTFP_ABI=1 -j4

On macOS, it may also be necessary to give the complete path to the ar utility in the make command above, like so:

AR=${NDK_BUNDLE_DIR}/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc-ar

otherwise you may get a linker error complaining like

malformed archive header
name at 8

when the native macOS ar command was invoked instead.

Building for ARMV8

# Set path to ndk-bundle
export NDK_BUNDLE_DIR=/path/to/ndk-bundle/

# Export PATH to contain directories of clang and aarch64-linux-android-* utilities
export PATH=${NDK_BUNDLE_DIR}/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/:${NDK_BUNDLE_DIR}/toolchains/llvm/prebuilt/linux-x86_64/bin:$PATH

# Setup LDFLAGS so that loader can find libgcc and pass -lm for sqrt
export LDFLAGS="-L${NDK_BUNDLE_DIR}/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/lib/gcc/aarch64-linux-android/4.9.x -lm"

# Setup the clang cross compile options
export CLANG_FLAGS="-target aarch64-linux-android --sysroot ${NDK_BUNDLE_DIR}/platforms/android-23/arch-arm64 -gcc-toolchain ${NDK_BUNDLE_DIR}/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/"

# Compile
make TARGET=ARMV8 ONLY_CBLAS=1 AR=ar CC="clang ${CLANG_FLAGS}" HOSTCC=gcc -j4

Note: using TARGET=CORTEXA57 in place of ARMV8 will pick up better optimized routines. Implementations for the CORTEXA57 target are compatible with all other ARMV8 targets.

Note: for NDK 23b, something as simple as:

export PATH=/opt/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/bin/:$PATH
make HOSTCC=gcc CC=/opt/android-ndk-r23b/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang ONLY_CBLAS=1 TARGET=ARMV8

appears to be sufficient on Linux.

Alternative build script for 3 architectures

This script will build OpenBLAS for 3 architecture (ARMV7, ARMV8, X86) and install them to /opt/OpenBLAS/lib. It was tested on macOS with NDK version 21.3.6528147.

export NDK=YOUR_PATH_TO_SDK/Android/sdk/ndk/21.3.6528147
export TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/darwin-x86_64

make clean
make \
    TARGET=ARMV7 \
    ONLY_CBLAS=1 \
    CC="$TOOLCHAIN"/bin/armv7a-linux-androideabi21-clang \
    AR="$TOOLCHAIN"/bin/arm-linux-androideabi-ar \
    HOSTCC=gcc \
    ARM_SOFTFP_ABI=1 \
    -j4
sudo make install

make clean
make \
    TARGET=CORTEXA57 \
    ONLY_CBLAS=1 \
    CC=$TOOLCHAIN/bin/aarch64-linux-android21-clang \
    AR=$TOOLCHAIN/bin/aarch64-linux-android-ar \
    HOSTCC=gcc \
-j4
sudo make install

make clean
make \
    TARGET=ATOM \
    ONLY_CBLAS=1 \
CC="$TOOLCHAIN"/bin/i686-linux-android21-clang \
AR="$TOOLCHAIN"/bin/i686-linux-android-ar \
HOSTCC=gcc \
ARM_SOFTFP_ABI=1 \
-j4
sudo make install

## This will build for x86_64 
make clean
make \
    TARGET=ATOM BINARY=64\
ONLY_CBLAS=1 \
CC="$TOOLCHAIN"/bin/x86_64-linux-android21-clang \
AR="$TOOLCHAIN"/bin/x86_64-linux-android-ar \
HOSTCC=gcc \
ARM_SOFTFP_ABI=1 \
-j4
sudo make install

You can find full list of target architectures in TargetList.txt

iPhone/iOS

As none of the current developers uses iOS, the following instructions are what was found to work in our Azure CI setup, but as far as we know this builds a fully working OpenBLAS for this platform.

Go to the directory where you unpacked OpenBLAS,and enter the following commands:

CC=/Applications/Xcode_12.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang

CFLAGS= -O2 -Wno-macro-redefined -isysroot /Applications/Xcode_12.4.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.4.sdk -arch arm64 -miphoneos-version-min=10.0

make TARGET=ARMV8 DYNAMIC_ARCH=1 NUM_THREADS=32 HOSTCC=clang NOFORTRAN=1

Adjust MIN_IOS_VERSION as necessary for your installation. E.g., change the version number to the minimum iOS version you want to target and execute this file to build the library.

MIPS

For MIPS targets you will need latest toolchains:

P5600 - MTI GNU/Linux Toolchain
I6400, P6600 - IMG GNU/Linux Toolchain

You can use following commandlines for builds:

IMG_TOOLCHAIN_DIR={full IMG GNU/Linux Toolchain path including "bin" directory -- for example, /opt/linux_toolchain/bin}
IMG_GCC_PREFIX=mips-img-linux-gnu
IMG_TOOLCHAIN=${IMG_TOOLCHAIN_DIR}/${IMG_GCC_PREFIX}

# I6400 Build (n32):
make BINARY=32 BINARY32=1 CC=$IMG_TOOLCHAIN-gcc AR=$IMG_TOOLCHAIN-ar FC="$IMG_TOOLCHAIN-gfortran -EL -mabi=n32" RANLIB=$IMG_TOOLCHAIN-ranlib HOSTCC=gcc CFLAGS="-EL" FFLAGS=$CFLAGS LDFLAGS=$CFLAGS TARGET=I6400

# I6400 Build (n64):
make BINARY=64 BINARY64=1 CC=$IMG_TOOLCHAIN-gcc AR=$IMG_TOOLCHAIN-ar FC="$IMG_TOOLCHAIN-gfortran -EL" RANLIB=$IMG_TOOLCHAIN-ranlib HOSTCC=gcc CFLAGS="-EL" FFLAGS=$CFLAGS LDFLAGS=$CFLAGS TARGET=I6400

# P6600 Build (n32):
make BINARY=32 BINARY32=1 CC=$IMG_TOOLCHAIN-gcc AR=$IMG_TOOLCHAIN-ar FC="$IMG_TOOLCHAIN-gfortran -EL -mabi=n32" RANLIB=$IMG_TOOLCHAIN-ranlib HOSTCC=gcc CFLAGS="-EL" FFLAGS=$CFLAGS LDFLAGS=$CFLAGS TARGET=P6600

# P6600 Build (n64):
make BINARY=64 BINARY64=1 CC=$IMG_TOOLCHAIN-gcc AR=$IMG_TOOLCHAIN-ar FC="$IMG_TOOLCHAIN-gfortran -EL" RANLIB=$IMG_TOOLCHAIN-ranlib HOSTCC=gcc CFLAGS="-EL" FFLAGS="$CFLAGS" LDFLAGS="$CFLAGS" TARGET=P6600

MTI_TOOLCHAIN_DIR={full MTI GNU/Linux Toolchain path including "bin" directory -- for example, /opt/linux_toolchain/bin}
MTI_GCC_PREFIX=mips-mti-linux-gnu
MTI_TOOLCHAIN=${IMG_TOOLCHAIN_DIR}/${IMG_GCC_PREFIX}

# P5600 Build:

make BINARY=32 BINARY32=1 CC=$MTI_TOOLCHAIN-gcc AR=$MTI_TOOLCHAIN-ar FC="$MTI_TOOLCHAIN-gfortran -EL"    RANLIB=$MTI_TOOLCHAIN-ranlib HOSTCC=gcc CFLAGS="-EL" FFLAGS=$CFLAGS LDFLAGS=$CFLAGS TARGET=P5600

FreeBSD

You will need to install the following tools from the FreeBSD ports tree:

lang/gcc
lang/perl5.12
ftp/curl
devel/gmake
devel/patch

To compile run the command:

$ gmake CC=gcc FC=gfortran

Cortex-M

Cortex-M is a widely used microcontroller that is present in a variety of industrial and consumer electronics. A common variant of the Cortex-M is the STM32F4xx series. Here, we will give instructions for building for that series.

First, install the embedded Arm GCC compiler from the Arm website. Then, create the following toolchain.cmake file:

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_C_COMPILER "arm-none-eabi-gcc.exe")
set(CMAKE_CXX_COMPILER "arm-none-eabi-g++.exe")

set(CMAKE_EXE_LINKER_FLAGS "--specs=nosys.specs" CACHE INTERNAL "")

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

Then build OpenBLAS with:

$ cmake .. -G Ninja -DCMAKE_C_COMPILER=arm-none-eabi-gcc -DCMAKE_TOOLCHAIN_FILE:PATH="toolchain.cmake" -DNOFORTRAN=1 -DTARGET=ARMV5 -DEMBEDDED=1

In your embedded application, the following functions need to be provided for OpenBLAS to work correctly:

void free(void* ptr);
void* malloc(size_t size);

Note

If you are developing for an embedded platform, it is your responsibility to make sure that the device has sufficient memory for malloc calls. Libmemory provides one implementation of malloc for embedded platforms.

If the OpenBLAS DLLs are not linked correctly, you may see an error like "The application was unable to start correctly (0xc000007b)", which typically indicates a mismatch between 32-bit and 64-bit libraries. ↩