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: 32
Popularity: 1.383735
First Submitted: 2012-05-10 22:50
Last Updated: 2016-09-01 22:05

Required by (50)

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)

sftrytry commented on 2013-11-09 01:57

Linking has no problem, but numpy just would not work.

On my 2nd i5, (3k, 3k) dot (3k, 3k) takes 2.8s with optimized version. Unoptimized one takes 91s as I just tested.

I am going to recompile everything to see if it works.

Here is my ldd info.
ldd /usr/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
linux-vdso.so.1 (0x00007fff78dfe000)
liblapack.so => /usr/lib/liblapack.so (0x00007f4de4a64000)
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007f4de46a3000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f4de42f8000)
libblas.so => /usr/lib/libblas.so (0x00007f4de3c45000)
libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f4de392e000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f4de362b000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f4de3414000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f4de31f6000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f4de2ff2000)
libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f4de2dee000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f4de5506000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f4de2be0000)
libquadmath.so.0 => /usr/lib/../lib/libquadmath.so.0 (0x00007f4de29a5000)

gborzi commented on 2013-11-09 01:42

Why do you mention cblas? numpy doesn't require this package. On my system I have python2-numpy and its lapack_lite.so points to (open)blas, i.e.
ldd /usr/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
linux-vdso.so.1 (0x00007fff9bdfe000)
liblapack.so => /usr/lib/liblapack.so (0x00007f43e093d000)
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007f43e057c000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f43e01d1000)
libblas.so => /usr/lib/libblas.so (0x00007f43dfb22000)
libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f43df80b000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f43df508000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f43df2f1000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f43df0d3000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f43deecf000)
libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f43deccb000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f43e13ce000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f43deabd000)
libquadmath.so.0 => /usr/lib/../lib/libquadmath.so.0 (0x00007f43de882000)

sftrytry commented on 2013-11-09 01:28

I used openblas 0.2.8 here. All the other libs are stock, including lapack, numpy and scipy. For cblas, I used the stock aur PKGBUILD.

The cpp linked to cblas worked fine. But stock numpy seemed not linked to openblas. I also tried to compile numpy from ABS, no luck.

gborzi commented on 2013-11-09 01:21

@sftrytry
I don't understand, did you use openblas 0.2.8 or stock blas?

sftrytry commented on 2013-11-09 00:51

"drop in" is not working for me, or I missed anyhting?

Here are my settings.
openblas 2.5/2.6 with lapack and cblas included. numpy scipy compiled against to them. I got numpy (3k, 3k) dot (3k, 3k) int 2.8s.

openblas 2.8. Stock lapack, numpy and scipy, aur cblas. Then numpy did not seem to be optimized. (3k, 3k) dot (3k, 3k) took forever as I used stock blas.

muon commented on 2013-09-27 19:05

When I did that in octave, it did use 2 processors, so it must not be an issue with openBLAS, perhaps something with the way numpy does things. Thanks.

gborzi commented on 2013-09-27 16:46

I don't have numpy installed so I can't check if it is a specific problem with numpy. I tried in octave (it's in the repos) and on my system it work on all 4 cores
octave:1> n=5000;
octave:2> A=rand(n,n);
octave:3> A*A;
Have you searched for bugreports about openblas on your processor?

muon commented on 2013-09-27 15:57

@gborzi
Thanks so much for the quick reply. I didn't know that BLAS shouldn't use hyperthreading, and that explains the NPROC. I ran the script with larger matrices (2000x2000 -- above that and it started taking very large amounts of time for each multiply), but it still only uses one processor.

gborzi commented on 2013-09-27 15:41

@muon
It works as a drop in replacement and you don't have to recompile. Your i7-2620M has actually 2 cores with hyperthreading, which appear as 4 processors, see http://ark.intel.com/products/52231.
The library is faster if it doesn't use hyperthreading.
Please try your numpy script with larger matrices, i.e. 5000x5000 and a smaller range.

muon commented on 2013-09-27 15:26

Should this just `drop-in' work as a replacement to the official repo blas with things that call blas like python2-numpy, or would I need to compile those things? If it's a drop in, is there something I'm missing about how to allow it to use more cores? I'm using an i7 with 4 processors (cat /proc/cpuinfo: https://gist.github.com/anonymous/6730250) but when I run a simple python2-numpy script to multiply matrices (https://gist.github.com/anonymous/6730300), it only uses one processor (according to htop). I did do "export OMP_NUM_THREADS=4 before calling the script as well, which didn't change anything. I also noticed that with the current PKGBUILD, it finds NCORE=2 for me. Is there a reason you did it this way rather than $(cat /proc/cpuinfo grep processor | wc -l)? I read over GotoBLAS_02QuickInstall.txt, but that didn't clarify for me. Not sure if this was the right place to ask?

gborzi commented on 2013-09-26 11:22

That's because cblas is disables as well, see the PKGBUILD (NO_CBLAS=1).
I choose to exclude cblas and lapack for this reason: suppose you compile a program like gmsh which requires both blas and lapack with a complete openblas installed. Then you decide to use the blas+lapack from the repos or another fast blas like atlas-lapack. gmsh won't work anymore and you will need to recompile it. This is also the reason for changing the soname of the library.
If you want to include LAPACK and/or cblas you can modify the PKGBUILD or create a new package in AUR (e.g. openblas-lapack).

gdon commented on 2013-09-25 13:39

The cblas header file and the like are not copied to /usr/include or wherever you want to put them with this PKGBUILD.

As well, openblas can replace both system BLAS and LAPACK. Why did you disable LAPACK building?

sitquietly commented on 2013-08-31 19:28

According to the README

If you compile this lib with USE_OPENMP=1, you should set OMP_NUM_THREADS environment variable. OpenBLAS ignores OPENBLAS_NUM_THREADS and GOTO_NUM_THREADS with USE_OPENMP=1.

Perhaps we should use OMP_NUM_THREADS=...

jdarch commented on 2013-08-03 10:10

I believe a hotfix release 0.2.8 was published. (http://github.com/xianyi/OpenBLAS/archive/v0.2.8.tar.gz) But I don't know for sure why the hotfix was necessary, appears to be some issue with AMD bulldozer/piledriver CPUs?

With regards to the compilation options mentioned earlier, would it be preferable to add a file setting ' OPENBLAS_MAIN_FREE=1' to /etc/profile.d/ or should we keep the compilation option 'NO_AFFINITY=1'. Does anyone have some knowledge on what would be preferable? I believe the former might give some people the choice to let it fix affinity if they want to (could result in a tiny improvement of performance) while the latter option makes sure affinity settings do not interfere with each other on multi-user systems.

gborzi commented on 2013-08-02 12:04

What's the problem? Why flagged out of date?

gborzi commented on 2013-07-30 13:47

Thanks derberni, I've updated the package according to your suggestion.

Anonymous comment on 2013-07-30 13:29

It would probably better to download the tar archive from http://github.com/xianyi/OpenBLAS/archive/v0.2.7.tar.gz and substituting the correct pkgvers for the 0.2.7. The way it is downloaded at the moment, the current trunk is downloaded as a tarball and therefore the md5 changes with every commit. The version above downloads the tarball corresponding to a specific tag.

gborzi commented on 2013-07-26 11:30

OK, I'll wait a few more days, hoping version 0.2.7 stabilizes, and then I'll update.

richli commented on 2013-07-26 10:33

Odd, even though the source is the same (v0.2.7), the tarball I get from github has a different revision (0b951b2) and md5sum (299fdb4b8dd40c4dd4111a3a2f7247b2). Was the git history rewritten?

gborzi commented on 2013-07-24 14:14

@tstenner
Thanks for your comment, tha package has been undated.

tstenner commented on 2013-07-24 13:06

There's a new release, the new MD5-sum is 5d3d0867952954ef4b58f9c7d0a21676 (line 16), the new revision is d234425 (19 and 31).

jdarch commented on 2013-06-25 13:46

I still believe setting NO-AFFINITY=1 for compilation is a good choice, but I have discovered setting the envoronment variable OPENBLAS_MAIN_FREE=1 could be another option.

gborzi commented on 2013-06-21 23:28

It seems you're right, I'm going to add NO_AFFINITY=1, but I won't change the pkgver. This change only affects multi-CPU systems.

jdarch commented on 2013-06-21 22:03

Hi gborzi,

I have still not tested it, but as far as I understand it leaving the affinity setting to OpenBLAS can lead to some nasty issues if software is not aware of this. People even go so far as to call it 'insanity on general purpose systems' (https://github.com/JuliaLang/julia/pull/3097#issuecomment-17887690). What I have read so far suggests it is probably best to use NO_AFFINITY=1, almost everywhere I read that would be the preferred setting for gp systems (which most Arch setup probably are) To quote one of these comments:
OpenBLAS uses processor affinity to go faster. However, in general, on a computer shared between several users, this causes processes to fight for the same CPU. We thus disable it here with the NO_AFFINITY flag.'
If I have some time to test the difference I will do so.

jdarch commented on 2013-06-21 09:35

Hi gborzi, I have not tested it, but as far as I understand it leaving the affinity setting to OpenBLAS can lead to some nasty issues if software is not aware of this. It is even called insanity on general purpose systems (https://github.com/JuliaLang/julia/pull/3097#issuecomment-17887690). What I have read so far suggests it is probably best to use NO_AFFINITY=1

gborzi commented on 2013-06-21 09:01

Hi jdarch,
I think it would make a difference only on multi-CPU systems. I don't have access to such systems, so I can't try it. If you have access at a multi-CPU systems you can see if the performance changes when you change CPU affinity (see man taskset).

jdarch commented on 2013-06-21 08:40

Thanks for creating and maintaining this package for arch, it drops right in. I was wondering about one thing: would adding NO_AFFINITY=1 be a bad idea? As far as I understand it could enhance explicit multi-threading performance at the cost of some overall decrease in performance.

gborzi commented on 2013-06-19 04:20

This updated package changes a few things:
1) removed cblas;
2) changed the soname to libblas.so.3;
in this way it is easier to switch back and forth between openblas and standard blas.

Anonymous comment on 2013-03-12 21:59

@gborzi
chuckatkins' patch actually makes sense. OpenBLAS, like ATLAS, also optimize part of LAPACK. But it is more friendly to packagers than ATLAS because it downloads the netlib LAPACK source and patch on top of it.

For octave, numpy and scipy etc, I never encountered any problem with OpenBLAS + repo LAPACK overriding OpenBLAS LAPACK. But with Torch7, I couldn't run through a demo for LAPACK corruption.

gborzi commented on 2013-02-18 17:19

@chuckatkins
The architecture auto-detection is the default at compile time, there isn't a default architecture. I've compiled this package on different architectures and got different libraries. Using DYNAMIC_ARCH=1 means that "All kernel will be included in the library and dynamically switched the best architecutre at run time" (from GotoBLAS_02QuickInstall.txt).
Also, I use the repo LAPACK with Openblas and it works fine for me, no need to add LAPACK (and LAPACKE) to the compilation. However, if you feel it is worth doing it, you can upload a different package (e.g. call it openblas-lapack).

Anonymous comment on 2013-02-18 07:28

Also, my patch makes the lib build with dynamic arch detection. This will let the library auto-detect the underlying cpu architecture instead of just using the defualt PENRYN.

Anonymous comment on 2013-02-18 07:25

Added LAPACK and LAPACKE build. This should be enough to replace atlas-lapack with openblas.

--BEGIN_PATCH--

--- PKGBUILD 2012-11-29 07:51:38.000000000 -0500
+++ PKGBUILD.lapack 2013-02-18 02:20:12.305927061 -0500
@@ -2,15 +2,15 @@
pkgname=openblas
_pkgname=xianyi-OpenBLAS
pkgver=0.2.5
-pkgrel=1
+pkgrel=2
pkgdesc="An optimized BLAS library based on GotoBLAS2 1.13 BSD "
arch=('i686' 'x86_64')
url="http://xianyi.github.com/OpenBLAS/"
license=('BSD')
depends=('gcc-libs')
makedepends=('perl' 'gcc-fortran')
-provides=('blas' 'cblas')
-conflicts=('blas' 'cblas')
+provides=('blas' 'cblas' 'lapack=3.4.2' 'lapacke=3.4.2')
+conflicts=('blas' 'cblas' 'lapack' 'lapacke')
options=(!makeflags)
source=(${_pkgname}-v${pkgver}.tar.gz::http://github.com/xianyi/OpenBLAS/tarball/v${pkgver})
md5sums=('f14384a108b12aae69bae2fae4d103de')
@@ -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
+ make DYNAMIC_ARCH=1 USE_OPENMP=1 NUM_THREADS=$NCORE
}

package() {
@@ -32,19 +32,42 @@
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 install
+ make PREFIX="$pkgdir/usr" DYNAMIC_ARCH=1 USE_OPENMP=1 NUM_THREADS=$NCORE install
install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"

cd "$pkgdir/usr/lib/"
- ln -sf libopenblas_*-r$pkgver.a libopenblas.a
- ln -sf libopenblas_*-r$pkgver.so libopenblas.so
- ln -sf libopenblas_*-r$pkgver.so libopenblas.so.0
- ln -sf libopenblas.so libblas.so.3
+
+ # Fix the installer's absolute symlinks with relative symlinks
+ rm libopenblas.a
+ rm libopenblas.so.0
+ rm libopenblas.so
+ ln -sf libopenblasp-r$pkgver.a libopenblas.a
+ ln -sf libopenblasp-r$pkgver.so libopenblas.so.0
+ ln -sf libopenblas.so.0 libopenblas.so
+
+ # Set up common BLAS and lapack library symlinks
+ ln -sf libopenblas.so libblas.so
ln -sf libopenblas.a libblas.a
- ln -sf libblas.so.3 libblas.so
- ln -sf libopenblas.so libcblas.so.3
+ ln -sf libopenblas.so libcblas.so
ln -sf libopenblas.a libcblas.a
- ln -sf libcblas.so.3 libcblas.so
+
+ # Set up lapack symlinks
+ ln -sf libopenblasp-r$pkgver.a liblapack.a
+ ln -sf liblapack.a liblapack.a.3
+ ln -sf liblapack.a.3 liblapack.a.3.4
+ ln -sf liblapack.a.3.4 liblapack.a.3.4.2
+ ln -sf libopenblasp-r$pkgver.so liblapack.so
+ ln -sf liblapack.so liblapack.so.3
+ ln -sf liblapack.so.3 liblapack.so.3.4
+ ln -sf liblapack.so.3.4 liblapack.so.3.4.2
+ ln -sf libopenblasp-r$pkgver.a liblapacke.a
+ ln -sf liblapacke.a liblapacke.a.3
+ ln -sf liblapacke.a.3 liblapacke.a.3.4
+ ln -sf liblapacke.a.3.4 liblapacke.a.3.4.2
+ ln -sf libopenblasp-r$pkgver.so liblapacke.so
+ ln -sf liblapacke.so liblapacke.so.3
+ ln -sf liblapacke.so.3 liblapacke.so.3.4
+ ln -sf liblapacke.so.3.4 liblapacke.so.3.4.2
}

# vim:set ts=2 sw=2 et:

--END_PATCH--

gborzi commented on 2012-10-15 10:06

Updated. Thanks to saimn for notifying the changes.

saimn commented on 2012-10-15 09:26

I had to change the md5sums to install the package :

md5sums=('9cf38495f165760deac063853bc5a849')

and

cd "$srcdir/$_pkgname-ea9a46c"