Search Criteria
Package Details: openblas-lapack 0.3.20-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/openblas-lapack.git (read-only, click to copy) |
---|---|
Package Base: | openblas-lapack |
Description: | Optimized BLAS library based on GotoBLAS2 1.13 BSD (providing blas, lapack, and cblas) |
Upstream URL: | http://www.openblas.net/ |
Licenses: | BSD |
Conflicts: | blas, cblas, lapack, lapacke, openblas |
Provides: | blas, cblas, lapack, lapacke, openblas |
Submitter: | sftrytry |
Maintainer: | thrasibule |
Last Packager: | thrasibule |
Votes: | 88 |
Popularity: | 0.092714 |
First Submitted: | 2013-11-20 23:53 (UTC) |
Last Updated: | 2022-02-25 19:33 (UTC) |
Dependencies (3)
- gcc-libs (fastgcc, gcc-libs-git)
- gcc-fortran (gccrs-fortran-git, gcc-fortran-git) (make)
- perl (perl-git) (make)
Required by (476)
- abinit (requires blas)
- abinit (requires lapack)
- algodoo (requires lapack)
- ambertools (requires blas)
- ambertools (requires lapack)
- amino-git (requires lapack)
- amino-git (requires cblas)
- armadillo (requires blas)
- armadillo (requires lapack)
- arpack++ (requires blas)
- arpack++ (requires lapack)
- arrayfire-git (requires cblas)
- arrayfire-git (requires lapack)
- astromatic-sextractor
- atompaw (requires lapack)
- avs-device-sdk (requires cblas)
- ball (requires lapack)
- bart
- bart-git
- blaze (requires blas) (make)
Latest Comments
thrasibule commented on 2022-02-01 02:33 (UTC)
sha256sum is still the same for me. I'm curious if you use this address: https://github.com/xianyi/OpenBLAS/releases/download/v0.3.19/OpenBLAS-0.3.19.tar.gz, is the sha256sum the same?
Cebtenzzre commented on 2022-01-27 21:09 (UTC)
The sha256sum of the patch changed. It is now 972aa53d2fbbe76b46a1cd1a9e53ddfeb42968e701e0cb8894a5bc3c1072847d.
thrasibule commented on 2021-12-29 19:07 (UTC)
@kwyjibo9999 Please report upstream if you have a reproducible example.
kwyjibo9999 commented on 2021-12-29 18:47 (UTC)
0.3.19 is causing crashes on x86_64 that go away with OMP_NUM_THREADS=1 but cause slowdowns. Are there upstream issues?
kwyjibo9999 commented on 2021-12-28 19:40 (UTC)
Upstream 0.3.19 version is out for two weeks. Will this be updated or is there trouble with the update?
evg commented on 2020-10-31 12:44 (UTC) (edited on 2020-10-31 12:45 (UTC) by evg)
@thrasibule, the output of
./getarch 0
isWith the change 1<<7 to 1<<5 (and without
-march=native
flag) everything builds fine.thrasibule commented on 2020-10-30 20:36 (UTC)
@liamtimms and @evg. Could you try to make the following change to cpuid_x86.c, line 222: try to change the 7 into a 5 (so that it reads 1<<5 instead of 1<<7 ) and recompile? I think it should now correctly reportthat your cpu doesn't have avx2, and also fix the build. I've filed an issue upstream here: https://github.com/xianyi/OpenBLAS/issues/2957. I don't have a cpu affected by it, so it would be good to test on yours.
liamtimms commented on 2020-10-30 19:29 (UTC) (edited on 2020-10-30 19:30 (UTC) by liamtimms)
@thrasibule does this bug belong with OpenBLAS upstream? We can file a github issue.
thrasibule commented on 2020-10-30 19:16 (UTC)
Thanks, there does seem a bug with the avx2 detection, cause both of your cpus don't seem to support it, yet HAVE_AVX2=1 gets enabled. I'll try to figure out what's wrong.
liamtimms commented on 2020-10-30 18:51 (UTC) (edited on 2020-10-30 18:51 (UTC) by liamtimms)
@thrasibule, I can confirm the same error in 0.3.12 with Intel but adding
-march=native
does let it build.and
looks like
./getarch 0
does giveHAVE_AVX2=1
.thrasibule commented on 2020-10-30 17:13 (UTC)
So it's very strange, looks like your cpu architecture should be Sandybridge indeed, which doesn't support avx2 (it doesn't show in the list of flags). There must be a bug in the avx2 detection then. What's the output of running
./getarch 0
in the src directory? It should be the same as what's already in Makefile.conf, but just to be sure. What's concerning is that now the package was buildt using the avx2 instructions, so the code will fails randomly if you don't have avx2 in your cpu.evg commented on 2020-10-30 16:01 (UTC) (edited on 2020-10-30 16:03 (UTC) by evg)
@thrasibule, the output of cat /proc/cpuinfo is
and seven more identical groups of lines.
With CFLAGS="${CFLAGS} -march=native" it now builds without problems. Thanks a lot for your quick help!
thrasibule commented on 2020-10-30 15:52 (UTC)
That's strange. Your cpu is detected as sandybridge, but yet you HAVE_AVX2=1. avx2 was not available until haswell. What's the output of cat /proc/cpuinfo? And can you try building with CFLAGS="-march=native"? Either change the line in the build section of the PKGBUILD to CFLAGS="${CFLAGS} -march=native" or change it in your makepkg.conf.
evg commented on 2020-10-30 15:45 (UTC) (edited on 2020-10-30 15:46 (UTC) by evg)
@thrasibule, yes, it is the new version 0.3.12. The content of Makefile.conf after failed compilation is
The content of /etc/makepkg.conf is
thrasibule commented on 2020-10-30 15:41 (UTC)
@evg, this should have been fixed with the new version. Can confirm this is with 0.3.12? What is the content of Makefile.conf after failed compilation? And which CFLAGS do you have in /etc/makepkg.conf?
evg commented on 2020-10-30 15:36 (UTC) (edited on 2020-10-30 15:37 (UTC) by evg)
fails to build on intel
liamtimms commented on 2020-10-21 22:57 (UTC) (edited on 2020-10-22 14:09 (UTC) by liamtimms)
@thrasibule thanks for the fast work! With your fixes in the new version it is now building. I've not done any testing beyond that but cheers.
thrasibule commented on 2020-10-21 15:05 (UTC)
I've just pushed a tentative fix. The issues upstream warns about seems to be missing symbols when the library is compiled statically. Since we build the shared library, we should be ok.
thrasibule commented on 2020-10-21 14:05 (UTC)
@damir, what's the target detected? It seems weird that it's trying to compile some arm kernels. You can see it in CORE and LIBCORE in Makefile.conf. If there are issues with the build system, they probably should be reported upstream.
liamtimms commented on 2020-10-21 13:59 (UTC) (edited on 2020-10-21 14:05 (UTC) by liamtimms)
@damir I have the same failed build log on intel+nvidia so I don't think it's hardware dependent.
I just built 0.3.10 without issue so I'd recommend anyone doing a fresh install right now to just go back to that. There's huge warnings on the github page (https://github.com/xianyi/OpenBLAS/releases) and the latest official release is still 0.3.10. If nobody can build with 0.3.11 it should not have been pushed to the AUR.
damir commented on 2020-10-20 21:57 (UTC) (edited on 2020-10-20 21:58 (UTC) by damir)
fails also to build for me - on ryzen 3950x:
haawda commented on 2020-10-20 19:54 (UTC)
Upstream notes for version 0.3.11:
Additionally, 0.3.11 does not build for me.
thrasibule commented on 2020-03-05 01:52 (UTC)
@kgizdov that's on purpose. Reference Blas 0.3.9 is not out yet, and definitely not part of openblas.
kgizdov commented on 2020-03-04 09:49 (UTC)
I think the blasver was not correctly updated - it should be 0.3.9
E3LDDfrK commented on 2020-02-04 17:30 (UTC)
So, since this one is compiled with openmp (
USE_OPENMP=1
), I supposeopenblas-lapack-openmp
is pointless now?samk commented on 2019-11-29 16:16 (UTC)
Just checked, and it creates libopenblas.so.3 instead of libopenblas.so.0. So, all good now. Thanks!
thrasibule commented on 2019-11-29 02:58 (UTC)
@samk, sorry I reverted some previous change by eolianoe, this should be working now.
samk commented on 2019-11-28 14:29 (UTC) (edited on 2019-11-28 14:29 (UTC) by samk)
I realized that some R package was looking for /usr/lib/libopenblas.so.3
However, with this PKGBUILD only libopenblas.so.0 is created.
Thus, I suggest to add the following lines to the PKGBUILD, in a similar way as for BLAS, CBLAS...., but of course without linking to itself:
# OPENBLAS
ln -sf libopenblas.so libopenblas.so.${_lapackver:0:1}
ln -sf libopenblas.so libopenblas.so.${_lapackver}
simonp commented on 2019-11-12 13:05 (UTC)
0.3.7: https://gist.github.com/a67bcb8ec51321d3838001f049379eb2
huyz commented on 2019-08-31 07:31 (UTC) (edited on 2019-08-31 07:32 (UTC) by huyz)
There's a bug of this package. It provides blas/cblas/lapack, but it doesn't provides "/usr/lib/pkgconfig/{blas.pc, cblas.pc, lapack.pc}", which makes some packages that requires these files failed to build against this package. The package openblas at community repo provides blas, and it does provides "/usr/lib/pkgconfig/blas.pc".
a.kudelin commented on 2019-05-06 20:49 (UTC)
@eolianoe If you was experiencing a problem with threaded OpenBLAS, please, open an issue on its github page. AFAIK, OpenBLAS is alright with OpenMP, moreover, openblas in the community repo comes with the option
USE_OPENMP=1
.eolianoe commented on 2019-05-06 19:16 (UTC)
@thrasibule: USE_COMPILER_TLS was needed to avoid a bug, I removed it @a.kudelin: BUILD_LAPACK_DEPRECATED is needed to build some old codes and OpenMP was bugguy a while back when using in a OpenMP, some tests are needed to check if everything is ok
a.kudelin commented on 2019-05-06 08:05 (UTC)
NO_LAPACK=0
is enough for LAPACK to be enabled, andBUILD_LAPACK_DEPRECATED=1
is excessive. Mb, it's worth to enable OpenMP?thrasibule commented on 2019-05-06 02:04 (UTC)
USE_COMPILER_TLS is not used anywhere in the code (I know it's disabled in the PKGBUILD, but if one tries to set it to 1, one might be surprised that it doesn't do anything.) You probably meant to use USE_TLS=0 instead.
petronny commented on 2019-05-05 18:28 (UTC)
Hi, this is not an
any
package. Please update itsarch
to('x86_64')
.eolianoe commented on 2019-04-29 15:11 (UTC)
@syamajala: this package provides BLAS and LAPACK but I think that only blas is optimised
syamajala commented on 2019-03-28 21:54 (UTC)
The this is packaged makes so much more sense to me than the community package. Is there a reason why the community one can't be replaced by this?
eolianoe commented on 2019-03-10 15:01 (UTC)
@alleut: it provides lapack @petronny: the PKGBUILD is now more in synced with the community one
commented on 2019-03-08 13:41 (UTC)
What's the current difference between this and the community package?
petronny commented on 2019-03-07 09:11 (UTC)
Hi,
openblas-lapack
is providing/usr/lib/libopenblas.so.0
.However,
openblas
in[community]
is providing/usr/lib/libopenblas.so.3
.Could you make them same?
leomao commented on 2018-08-21 03:56 (UTC) (edited on 2018-08-21 03:58 (UTC) by leomao)
There is another issue and the linked PR(https://github.com/xianyi/OpenBLAS/pull/1739). Should we use this patch? I applied this patch instead of the original patch and verified that the issue resolved.
kgizdov commented on 2018-08-20 14:10 (UTC)
The patch itself does not do anything, unless you pass the
USE_COMPILER_TLS=0
flag at compilation.zauster commented on 2018-08-18 12:43 (UTC)
Tested the patch by kgizdov, works like a charm!
kgizdov commented on 2018-08-11 17:12 (UTC) (edited on 2018-08-11 17:55 (UTC) by kgizdov)
Rerefencing the following issue and linked PR and discussion, I made some changes to the package(here) to make GIMP work and remove glibc deadlocks. Do you think it would be nice to include it, while it's still resolved?
solnce commented on 2018-07-30 07:58 (UTC)
Update is out: https://github.com/xianyi/OpenBLAS/archive/v0.3.2.tar.gz
adfjjv commented on 2018-07-25 11:38 (UTC)
OpenBLAS 0.3.1 is broken when running multi-threaded. Rediscovered this myself, then found https://github.com/xianyi/OpenBLAS/issues/1666 and https://github.com/xianyi/OpenBLAS/issues/1673 Workaround is OPENBLAS_NUM_THREADS=1
Until fix is released, please revert to 0.3.0 (or 0.2.20?). Who here wants their BLAS to be giving incorrect results? Scary that it's been broken for a month now. How many people's work for the past month has been ruined? Author is in no hurry to release a fix, either.
This package should not track upstream so aggressively!
Rufflewind commented on 2018-07-16 01:08 (UTC)
Typo: USE_OPENMP, not USE_OPENMPI
Rufflewind commented on 2018-07-16 01:08 (UTC)
There is a compatibility issue with GIMP that causes GIMP to hang during startup.
https://github.com/xianyi/OpenBLAS/issues/240#issuecomment-405120893
Workaround: rebuild openblas-lapack with USE_OPENMPI=1 (see PKGBUILD file) instead of USE_OPENMP=0.
jerry73204 commented on 2018-05-10 17:41 (UTC)
The dependency gcc-libs changes the version number of shared library
libgfortran.so.5
from 4 to 5. I suggest to increase the pkgrel to enforce re-building of this package.eolianoe commented on 2018-03-19 21:06 (UTC)
@asitdepends: why do you need static libs? If you want them, you juste need to staticlibs to the options
asitdepends commented on 2018-03-11 14:04 (UTC)
Would you update the package to make the static libraries also?
MaartenBaert commented on 2017-10-08 20:05 (UTC)
adfjjv commented on 2017-10-08 09:27 (UTC)
MaartenBaert commented on 2017-10-07 03:15 (UTC) (edited on 2017-10-07 03:20 (UTC) by MaartenBaert)
MaartenBaert commented on 2017-10-07 02:29 (UTC)
adfjjv commented on 2017-10-05 17:12 (UTC)
MaartenBaert commented on 2017-10-02 02:45 (UTC)
eolianoe commented on 2017-07-14 14:42 (UTC)
solnce commented on 2017-07-14 07:49 (UTC)
richli commented on 2017-07-13 19:00 (UTC)
eolianoe commented on 2017-07-10 17:26 (UTC)
xyproto commented on 2017-07-10 16:15 (UTC)
marcs commented on 2017-07-06 10:19 (UTC) (edited on 2017-07-06 10:35 (UTC) by marcs)
adfjjv commented on 2017-06-28 14:33 (UTC)
eolianoe commented on 2017-06-26 14:05 (UTC)
adfjjv commented on 2017-06-24 05:30 (UTC) (edited on 2017-06-24 05:30 (UTC) by adfjjv)
eolianoe commented on 2017-06-23 20:10 (UTC)
adfjjv commented on 2017-06-23 17:04 (UTC)
eolianoe commented on 2017-06-23 12:49 (UTC)
marcs commented on 2017-06-23 12:17 (UTC)
eolianoe commented on 2017-06-19 09:05 (UTC)
marcs commented on 2017-06-19 07:32 (UTC)
eolianoe commented on 2017-06-16 10:48 (UTC)
marcs commented on 2017-06-16 08:48 (UTC)
eolianoe commented on 2017-06-08 12:38 (UTC)
marcs commented on 2017-06-08 07:59 (UTC)
eolianoe commented on 2017-06-03 11:32 (UTC)
nivata commented on 2017-06-02 17:10 (UTC)
eolianoe commented on 2017-06-01 14:34 (UTC) (edited on 2017-06-01 14:35 (UTC) by eolianoe)
dbermond commented on 2017-05-29 21:35 (UTC)
eolianoe commented on 2017-04-29 15:48 (UTC)
ewtoombs commented on 2017-04-28 21:56 (UTC) (edited on 2017-04-28 22:02 (UTC) by ewtoombs)
Fandekasp commented on 2017-02-22 05:11 (UTC)
chicomag commented on 2016-12-18 02:35 (UTC)
flocke commented on 2016-09-06 08:08 (UTC)
eolianoe commented on 2016-09-05 12:46 (UTC)
flocke commented on 2016-09-05 07:43 (UTC)
eolianoe commented on 2016-05-30 18:57 (UTC)
buzz777 commented on 2016-05-30 18:32 (UTC)
commented on 2016-04-30 09:47 (UTC)
commented on 2016-04-30 05:34 (UTC)
eolianoe commented on 2016-04-28 07:49 (UTC)
berquist commented on 2016-04-27 19:31 (UTC)
commented on 2016-04-27 17:41 (UTC)
anntzer commented on 2016-02-06 07:33 (UTC)
pavanky commented on 2015-12-30 05:44 (UTC)
eolianoe commented on 2015-10-07 07:22 (UTC)
alexanderp commented on 2015-10-06 19:31 (UTC)
eolianoe commented on 2015-10-06 11:30 (UTC)
alexanderp commented on 2015-10-05 21:00 (UTC)
aquarix commented on 2015-06-09 11:40 (UTC)
Rufflewind commented on 2015-06-04 00:48 (UTC)
hllowrld commented on 2015-02-26 22:28 (UTC)
eolianoe commented on 2015-02-25 21:47 (UTC)
aphirst commented on 2015-02-16 13:20 (UTC)
SuperBo commented on 2015-02-02 09:24 (UTC)
aphirst commented on 2014-07-05 19:25 (UTC)
aphirst commented on 2014-07-05 17:28 (UTC)
sftrytry commented on 2014-06-18 05:42 (UTC)
sftrytry commented on 2013-11-23 02:05 (UTC)
Xyne commented on 2013-11-23 01:44 (UTC)
sftrytry commented on 2013-11-20 23:58 (UTC)