Skip to content
This repository has been archived by the owner on Jan 23, 2022. It is now read-only.
/ gentoo-blas-lapack Public archive

experimental mechanisms for chain loading BLAS/LAPACK at runtime

License

Notifications You must be signed in to change notification settings

bsd-ac/gentoo-blas-lapack

Repository files navigation

# Gentoo BLAS/LAPACK chain loading

**This is still a bit experimental.**

## Overview

Netlib specifications do not mandate the presence of BLAS/LAPACK/etc symbols to be present
in the same library. In fact, they do not even require the libraries to be named
`libblas.so, libcblas.so` or otherwise

This mechanism strictly follows those recommendations and allows creation of dummy
empty libraries, which chain load the libraries with actual symbols, resulting in a
very simple technique to link any library (or set of libaries) as a provider.

## Advantages

- Very simple eclass to register a provider
- No fiddling around with sources to find exact speficications
- Allows using Intel MKL as a BLAS/LAPACK provider

## Disadvantages

none that are evident

## Testings

So far, testing has been done with numpy and scipy, both heavy users of these libraries
and they have been working perfectly.

## Debugging

There are some simple programs in the DEBUG directory which contains C++, fortran and
python code to do a very simple matrix multiplication of 1500x1500.

To check if the BLAS LAPACK switch has worked on your computer just go into the
DEBUG directory and do - make run.
There should be a noticeable difference in the run time after doing a switch
using eselect library set blas <openblas/mkl> as opposed to when you do not have
any provider selected - eselect library unset blas

About

experimental mechanisms for chain loading BLAS/LAPACK at runtime

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages