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/Kali"

```bash
$ sudo apt update
$ sudo apt install libopenblas-dev
```
OpenBLAS can be configured as the default BLAS through the `update-alternatives` mechanism:

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

=== "openSUSE/SLE"

```bash
$ sudo zypper refresh
$ sudo zypper install openblas-devel
```

OpenBLAS can be configured as the default BLAS through the `update-alternatives` mechanism:
```bash
$ sudo update-alternatives --config libblas.so.3
```

=== "Fedora/CentOS/RHEL"

```bash
$ 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](https://www.mpi-magdeburg.mpg.de/projects/flexiblas) (which
    uses OpenBLAS by default as its backend on Fedora), which you can install with:

    ```bash
    $ dnf install flexiblas-devel
    ```

For CentOS and RHEL, OpenBLAS packages are provided via the [Fedora EPEL repository](https://fedoraproject.org/wiki/EPEL).
After adding that repository and its repository keys, you can install
`openblas-devel` with either `dnf` or `yum`.

=== "Arch/Manjaro/Antergos"

```bash
$ sudo pacman -S openblas
```

Windows

=== "Conda-forge"

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](https://conda-forge.org/docs/maintainer/knowledge_base/#switching-blas-implementation)
for more details).

=== "vcpkg"

OpenBLAS can be installed with vcpkg:
```cmd
# In classic mode:
vcpkg install openblas

# Or in manifest mode:
vcpkg add port openblas
```

=== "OpenBLAS releases"

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](http://sourceforge.net/projects/openblas/files); this is
mostly of historical interest.

macOS

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

=== "Homebrew"

```zsh
% brew install openblas
```

=== "MacPorts"

```zsh
% sudo port install OpenBLAS-devel
```

=== "Conda-forge"

```zsh
% 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](https://conda-forge.org/docs/maintainer/knowledge_base/#switching-blas-implementation)
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](user_manual.md#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.

!!! tip "Change in complex types for Visual Studio 2017 and up"

In newer Visual Studio versions, Microsoft has changed
[how it handles complex types](https://docs.microsoft.com/en-us/cpp/c-runtime-library/complex-math-support?view=msvc-170#types-used-in-complex-math).
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:

```c
#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](https://github.com/OpenMathLib/OpenBLAS/issues/3661),
[lapack#683](https://github.com/Reference-LAPACK/lapack/issues/683), and
[this Stack Overflow question](https://stackoverflow.com/questions/47520244/using-openblas-lapacke-in-visual-studio).

!!! warning "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 .

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.

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.

!!! info "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](http://www.eclipse.org/cdt/) or
  [Qt Creator](http://qt.nokia.com/products/developer-tools/).

Windows on Arm

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

Clang for Windows on Arm. Find the latest LLVM build for WoA from LLVM release page. E.g: LLVM 12 build for WoA64 can be found here Run the LLVM installer and ensure that LLVM is added to environment PATH.
Download and install classic Flang for Windows on Arm. Classic Flang is the only available Fortran compiler for Windows on Arm for now. A pre-release build can be found here There is no installer for classic flang and the zip package can be extracted and the path needs to be added to environment PATH. E.g., in PowerShell:
```
$env:Path += ";C:\flang_woa\bin"
```

The following steps describe how to build the static library for OpenBLAS with and without LAPACK:

Build OpenBLAS static library with BLAS and LAPACK routines with Make:

$ make CC="clang-cl" HOSTCC="clang-cl" AR="llvm-ar" BUILD_WITHOUT_LAPACK=0 NOFORTRAN=0 DYNAMIC_ARCH=0 TARGET=ARMV8 ARCH=arm64 BINARY=64 USE_OPENMP=0 PARALLEL=1 RANLIB="llvm-ranlib" MAKE=make F_COMPILER=FLANG FC=FLANG FFLAGS_NOOPT="-march=armv8-a -cpp" FFLAGS="-march=armv8-a -cpp" NEED_PIC=0 HOSTARCH=arm64 libs netlib

Build static library with BLAS routines using CMake:

Classic Flang has compatibility issues with CMake, hence only BLAS routines can be compiled with CMake:

$ mkdir build
$ cd build
$ cmake ..  -G Ninja -DCMAKE_C_COMPILER=clang -DBUILD_WITHOUT_LAPACK=1 -DNOFORTRAN=1 -DDYNAMIC_ARCH=0 -DTARGET=ARMV8 -DARCH=arm64 -DBINARY=64 -DUSE_OPENMP=0 -DCMAKE_SYSTEM_PROCESSOR=ARM64 -DCMAKE_CROSSCOMPILING=1 -DCMAKE_SYSTEM_NAME=Windows
$ cmake --build . --config Release

!!! tip "getarch.exe execution error"

If you notice that platform-specific headers by `getarch.exe` are not
generated correctly, this could be due to a known debug runtime DLL issue for
arm64 platforms. Please check out [this page](https://linaro.atlassian.net/wiki/spaces/WOAR/pages/28677636097/Debug+run-time+DLL+issue#Workaround)
for a workaround.

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.

=== "MSVC"

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](use_visual_studio.md#generate-import-library-before-0210-version).

=== "MinGW"

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).

!!! info "Historic note"

Since NDK version 19, the default toolchain is provided as a standalone
toolchain, so building one yourself following
[building a standalone toolchain](http://developer.android.com/ndk/guides/standalone_toolchain.html)
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.

??? note "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.

```bash
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](https://github.com/OpenMathLib/OpenBLAS/blob/develop/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](https://github.com/embeddedartistry/libmemory)
provides one implementation of `malloc` for embedded platforms.

Footnotes

↩

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

install.md

install.md

Install OpenBLAS

Installing with a package manager

Linux

Windows

macOS

FreeBSD

Building from source

Linux and macOS

Windows

Visual Studio & native Windows ABI

CMake & Visual Studio integration

Build OpenBLAS for Universal Windows Platform

MinGW & GNU ABI

Windows on Arm

Generating an import library

Android

Building for ARMV7

Building for ARMV8

iPhone/iOS

MIPS

FreeBSD

Cortex-M

Files

install.md

Latest commit

History

install.md

File metadata and controls

Install OpenBLAS

Installing with a package manager

Linux

Windows

macOS

FreeBSD

Building from source

Linux and macOS

Windows

Visual Studio & native Windows ABI

CMake & Visual Studio integration

Build OpenBLAS for Universal Windows Platform

MinGW & GNU ABI

Windows on Arm

Generating an import library

Android

Building for ARMV7

Building for ARMV8

iPhone/iOS

MIPS

FreeBSD

Cortex-M

Footnotes