Package Details: openblas 0.2.19-1

Git Clone URL: https://aur.archlinux.org/openblas.git (read-only)
Package Base: openblas
Description: An optimized BLAS library based on GotoBLAS2 1.13 BSD
Upstream URL: http://www.openblas.net/
Licenses: BSD
Conflicts: blas
Provides: blas=3.6.0
Submitter: gborzi
Maintainer: gborzi
Last Packager: gborzi
Votes: 30
Popularity: 0.108231
First Submitted: 2012-05-10 22:50
Last Updated: 2016-09-01 22:05

Required by (49)

Sources (1)

Latest Comments

SuperBo commented on 2016-09-01 10:40

Please update to newer version. 0.2.19 is available

xantares commented on 2015-11-26 14:19

hi,
is there a chance that lapack & cblas interfaces get enabled by this package instead of having a separate openblas-lapack one ?
It requires to set NO_LAPACK=0, NO_CBLAS=0 and make the corresponding symlinks.

alexanderp commented on 2015-10-05 21:01

You should be using `/usr/bin/grep` to bypass any aliases set by the user

oniram commented on 2015-08-12 17:32

Ok, I understand the problem. Maybe it's better to leave the package as is to avoid confusing other packages that link directly to libopenblas.so when given the choice, as I assume gmsh does. I can fix my problem with a simple extra link.

About the compatibility issues, they're caused by lack of flexibility in the building process, which looks for libopenblas.so and only libopenblas.so. I suggested to add more flexibility so the code compiles in my archlinux machine and my co-worker's debian machine. His response: "UNACCEPTABLE! Debian is the only true way!".

gborzi commented on 2015-08-12 16:27

Hello Oniram,
it was done this way earlier, i.e. I left libopenblas as the soname and simply made the libblas* links. There was however a problem with this approach. Every time you compile an AUR package that links to blas, e.g. gmsh, it will actually link to openblas if it is currently installed. So, if you later install stock blas these packages won't work anymore and you'll have to recompile them.
But I fail to understand the problem with Debian. How can these naming conventions create compatibility issue? Arch and Debian are not related, it's not that one is based on the other, neither we have (and can have) common repos.
I'd like to understand the reasons before making a change.

Regards.

oniram commented on 2015-08-12 16:09

I have a humble suggestion. I like the idea of installing this library as libblas.so, as gborzi says "that way it is easier to switch back and forth between openblas and standard blas".
However, I feel that the way it's currently done does not follow the default behavior of the OpenBLAS package, which by default installs its libraries as libopenblas.so. And this may create compatibility issues with other linux distributions, like for example debian that uses the default naming: libopenblas.so

I have been bitten by this myself when my unreasonable debian based co-developer refused to allow a simple change to the build config to also look for libblas.so.

I propose to allow the default naming but also add extra libblas.* links to provide the intended flexibility. Below is a patch to implement this:

--- PKGBUILD.orig 2015-08-12 09:31:37.000000000 -0600
+++ PKGBUILD 2015-08-12 09:45:07.326692151 -0600
@@ -23,7 +23,7 @@
NPROC=`grep "physical id" /proc/cpuinfo|sort|uniq|wc -l`
NCORE4PROC=`grep "cores" /proc/cpuinfo|sort|tail -n 1|sed -e 's/cpu cores.*: //'`
let NCORE=NPROC*NCORE4PROC
- make USE_OPENMP=1 NO_LAPACK=1 NUM_THREADS=$NCORE LIBPREFIX=libblas \
+ make USE_OPENMP=1 NO_LAPACK=1 NUM_THREADS=$NCORE \
MAJOR_VERSION=3 NO_CBLAS=1 NO_AFFINITY=1
}

@@ -33,15 +33,15 @@
NPROC=`grep "physical id" /proc/cpuinfo|sort|uniq|wc -l`
NCORE4PROC=` grep "cores" /proc/cpuinfo|sort|tail -n 1|sed -e 's/cpu cores.*: //'`
let NCORE=NPROC*NCORE4PROC
- make PREFIX="$pkgdir/usr" NUM_THREADS=$NCORE LIBPREFIX=libblas \
+ make PREFIX="$pkgdir/usr" NUM_THREADS=$NCORE \
MAJOR_VERSION=3 install
rm -f "$pkgdir/usr/include/cblas.h" "$pkgdir"/usr/include/lapacke*
install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"

cd "$pkgdir/usr/lib/"
- ln -sf libblas_*-r$pkgver.a libblas.a
- ln -sf libblas_*-r$pkgver.so libblas.so
- ln -sf libblas_*-r$pkgver.so libblas.so.3
+ ln -sf libopenblas_*-r$pkgver.a libblas.a
+ ln -sf libopenblas_*-r$pkgver.so libblas.so
+ ln -sf libopenblas_*-r$pkgver.so libblas.so.3
sed -i -e "s%$pkgdir%%" "$pkgdir/usr/lib/cmake/openblas/OpenBLASConfig.cmake"
}

gborzi commented on 2014-07-17 23:02

Why out of date?

xia0er commented on 2013-11-18 17:43

@sftrytry, I am maintaining the python2-numpy-openblas package (https://aur.archlinux.org/packages/python2-numpy-openblas/) and am having the same problem as you did - matrix dot isn't optimized. I tried your patch, but I don't seem to be able to get it to work either. Could you help have a look of my PKGBUILD and opt.patch file and see if there is any mistake? I have tried to turn off the NO_ATLAS_INFO patch in PKGBUILD that used to work, but it doesn't seem to help either. Thanks!

sftrytry commented on 2013-11-09 03:23

I found out the difference. And I used the script here "http://dpinte.wordpress.com/2010/01/15/numpy-performance-improvement-with-the-mkl/"

Here is my result.

everything stock, nothing optimized;
openblas with everything else stock, other operations optimized except matrix dot;
everything recompiled, numpy with the opt patch, all operations optimized.

sftrytry commented on 2013-11-09 02:22

I recompiled lapack and numpy against openblas 0.2.8. Then numpy got optimized again.

I patched numpy to use "opt blas"

diff -rup numpy-1.7.0b2/numpy/distutils/system_info.py patched/numpy/distutils/system_info.py
--- numpy-1.7.0b2/numpy/distutils/system_info.py 2012-09-04 17:31:31.000000000 -0400
+++ patched/numpy/distutils/system_info.py 2012-12-16 09:40:45.944452556 -0500
@@ -1340,10 +1340,16 @@ Make sure that -lgfortran is used for C+

class lapack_opt_info(system_info):

+ section = 'lapack_opt'
notfounderror = LapackNotFoundError

def calc_info(self):

+ info = self.calc_libraries_info()
+ if info:
+ self.set_info(**info)
+ return
+
if sys.platform == 'darwin' and not os.environ.get('ATLAS', None):
args = []
link_args = []
@@ -1429,10 +1435,16 @@ class lapack_opt_info(system_info):

class blas_opt_info(system_info):

+ section = 'blas_opt'
notfounderror = BlasNotFoundError

def calc_info(self):

+ info = self.calc_libraries_info()
+ if info:
+ self.set_info(**info)
+ return
+
if sys.platform == 'darwin' and not os.environ.get('ATLAS', None):
args = []
link_args = []


Here is the new ldd info.

ldd /usr/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
linux-vdso.so.1 (0x00007fff093fc000)
liblapack.so => /usr/lib/liblapack.so (0x00007f73258b8000)
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007f73254f7000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f73252d9000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f7324f2d000)
libblas.so => /usr/lib/libblas.so (0x00007f732487b000)
libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f7324564000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f7324260000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f732404a000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f7323e46000)
libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f7323c42000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f732635a000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f7323a34000)
libquadmath.so.0 => /usr/lib/../lib/libquadmath.so.0 (0x00007f73237f8000)

All comments