Package Details: openblas-lapack 0.3.20-1

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.088831
First Submitted: 2013-11-20 23:53 (UTC)
Last Updated: 2022-02-25 19:33 (UTC)

Required by (477)

Sources (1)

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 is

CORE=SANDYBRIDGE
LIBCORE=sandybridge
NUM_CORES=8
HAVE_MMX=1
HAVE_SSE=1
HAVE_SSE2=1
HAVE_SSE3=1
HAVE_SSSE3=1
HAVE_SSE4_1=1
HAVE_SSE4_2=1
HAVE_AVX=1
HAVE_AVX2=1
MAKE += -j 8

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

~$ cat /proc/cpuinfo

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 62
model name  : Intel(R) Core(TM) i7-4820K CPU @ 3.70GHz
stepping    : 4
microcode   : 0x42e
cpu MHz     : 1606.396
cache size  : 10240 KB
physical id : 0
siblings    : 8
core id     : 0
cpu cores   : 4
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips    : 7399.70
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

and 

openblas-lapack/src/OpenBLAS-0.3.12[master]$ ./getarch 0

CORE=SANDYBRIDGE
LIBCORE=sandybridge
NUM_CORES=8
HAVE_MMX=1
HAVE_SSE=1
HAVE_SSE2=1
HAVE_SSE3=1
HAVE_SSSE3=1
HAVE_SSE4_1=1
HAVE_SSE4_2=1
HAVE_AVX=1
HAVE_AVX2=1
MAKE += -j 8

looks like ./getarch 0 does give HAVE_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

processor    : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 58
model name  : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
stepping    : 9
microcode   : 0x21
cpu MHz     : 2837.041
cache size  : 8192 KB
physical id : 0
siblings    : 8
core id     : 0
cpu cores   : 4
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d
vmx flags   : vnmi preemption_timer invvpid ept_x_only flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips    : 6787.43
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

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

OSNAME=Linux
ARCH=x86_64
C_COMPILER=GCC
BINARY32=
BINARY64=1
CEXTRALIB=-L/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../..  -lpthread -lc  
F_COMPILER=GFORTRAN
FC=gfortran
BU=_
FEXTRALIB=-L/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../..  -lgfortran -lm -lgomp -lquadmath -lm -lpthread -lc  
CORE=SANDYBRIDGE
LIBCORE=sandybridge
NUM_CORES=8
HAVE_MMX=1
HAVE_SSE=1
HAVE_SSE2=1
HAVE_SSE3=1
HAVE_SSSE3=1
HAVE_SSE4_1=1
HAVE_SSE4_2=1
HAVE_AVX=1
HAVE_AVX2=1
MAKE += -j 8
SBGEMM_UNROLL_M=8
SBGEMM_UNROLL_N=4
SGEMM_UNROLL_M=16
SGEMM_UNROLL_N=4
DGEMM_UNROLL_M=8
DGEMM_UNROLL_N=4
QGEMM_UNROLL_M=2
QGEMM_UNROLL_N=2
CGEMM_UNROLL_M=8
CGEMM_UNROLL_N=2
ZGEMM_UNROLL_M=1
ZGEMM_UNROLL_N=4
XGEMM_UNROLL_M=1
XGEMM_UNROLL_N=1
CGEMM3M_UNROLL_M=4
CGEMM3M_UNROLL_N=8
ZGEMM3M_UNROLL_M=2
ZGEMM3M_UNROLL_N=8
XGEMM3M_UNROLL_M=2
XGEMM3M_UNROLL_N=2

The content of /etc/makepkg.conf is

#
# /etc/makepkg.conf
#

#########################################################################
# SOURCE ACQUISITION
#########################################################################
#
#-- The download utilities that makepkg should use to acquire sources
#  Format: 'protocol::agent'
DLAGENTS=('file::/usr/bin/curl -gqC - -o %o %u'
          'ftp::/usr/bin/curl -gqfC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u'
          'http::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
          'https::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
          'rsync::/usr/bin/rsync --no-motd -z %u %o'
          'scp::/usr/bin/scp -C %u %o')

# Other common tools:
# /usr/bin/snarf
# /usr/bin/lftpget -c
# /usr/bin/wget

#-- The package required by makepkg to download VCS sources
#  Format: 'protocol::package'
VCSCLIENTS=('bzr::bzr'
            'git::git'
            'hg::mercurial'
            'svn::subversion')

#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j$(($(nproc)+1))"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

#########################################################################
# BUILD ENVIRONMENT
#########################################################################
#
# Defaults: BUILDENV=(!distcc color !ccache check !sign)
#  A negated environment option will do the opposite of the comments below.
#
#-- distcc:   Use the Distributed C/C++/ObjC compiler
#-- color:    Colorize output messages
#-- ccache:   Use ccache to cache compilation
#-- check:    Run the check() function if present in the PKGBUILD
#-- sign:     Generate PGP signature file
#
BUILDENV=(!distcc color !ccache check !sign)
#
#-- If using DistCC, your MAKEFLAGS will also need modification. In addition,
#-- specify a space-delimited list of hosts running in the DistCC cluster.
#DISTCC_HOSTS=""
#
#-- Specify a directory for package building.
#BUILDDIR=/tmp/makepkg

#########################################################################
# GLOBAL PACKAGE OPTIONS
#   These are default values for the options=() settings
#########################################################################
#
# Default: OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug)
#  A negated option will do the opposite of the comments below.
#
#-- strip:      Strip symbols from binaries/libraries
#-- docs:       Save doc directories specified by DOC_DIRS
#-- libtool:    Leave libtool (.la) files in packages
#-- staticlibs: Leave static library (.a) files in packages
#-- emptydirs:  Leave empty directories in packages
#-- zipman:     Compress manual (man and info) pages in MAN_DIRS with gzip
#-- purge:      Remove files specified by PURGE_TARGETS
#-- debug:      Add debugging flags as specified in DEBUG_* variables
#
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug)

#-- File integrity checks to use. Valid: md5, sha1, sha256, sha384, sha512
INTEGRITY_CHECK=(md5)
#-- Options to be used when stripping binaries. See `man strip' for details.
STRIP_BINARIES="--strip-all"
#-- Options to be used when stripping shared libraries. See `man strip' for details.
STRIP_SHARED="--strip-unneeded"
#-- Options to be used when stripping static libraries. See `man strip' for details.
STRIP_STATIC="--strip-debug"
#-- Manual (man and info) directories to compress (if zipman is specified)
MAN_DIRS=({usr{,/local}{,/share},opt/*}/{man,info})
#-- Doc directories to remove (if !docs is specified)
DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
#-- Files to be removed from all packages (if purge is specified)
PURGE_TARGETS=(usr/{,share}/info/dir .packlist *.pod)
#-- Directory to store source code in for debug packages
DBGSRCDIR="/usr/src/debug"

#########################################################################
# PACKAGE OUTPUT
#########################################################################
#
# Default: put built package and cached source in build directory
#
#-- Destination: specify a fixed directory where all packages will be placed
#PKGDEST=/home/packages
#-- Source cache: specify a fixed directory where source files will be cached
#SRCDEST=/home/sources
#-- Source packages: specify a fixed directory where all src packages will be placed
#SRCPKGDEST=/home/srcpackages
#-- Log files: specify a fixed directory where all log files will be placed
#LOGDEST=/home/makepkglogs
#-- Packager: name/email of the person or organization building packages
#PACKAGER="John Doe <john@doe.com>"
#-- Specify a key to use for package signing
#GPGKEY=""

#########################################################################
# COMPRESSION DEFAULTS
#########################################################################
#
COMPRESSGZ=(gzip -c -f -n)
COMPRESSBZ2=(bzip2 -c -f)
COMPRESSXZ=(xz -c -z -)
COMPRESSZST=(zstd -c -z -q -)
COMPRESSLRZ=(lrzip -q)
COMPRESSLZO=(lzop -q)
COMPRESSZ=(compress -c -f)
COMPRESSLZ4=(lz4 -q)
COMPRESSLZ=(lzip -c -f)

#########################################################################
# EXTENSION DEFAULTS
#########################################################################
#
PKGEXT='.pkg.tar.xz'
SRCEXT='.src.tar.gz'

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

In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h: In function ‘v_muladd_f32’:
../kernel/x86_64/../arm/../simd/intrin_avx.h:25:5: warning: AVX vector return without AVX enabled changes the ABI [-Wpsabi]
   25 |     { return v_add_f32(v_mul_f32(a, b), c); }
      |     ^
../kernel/x86_64/../arm/../simd/intrin_avx.h: In function ‘v_sum_f32’:
../kernel/x86_64/../arm/../simd/intrin_avx.h:31:20: note: the ABI for passing parameters with 32-byte alignment has changed in GCC 4.6
   31 | BLAS_FINLINE float v_sum_f32(__m256 a)
      |                    ^~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/immintrin.h:51,
                 from ../kernel/x86_64/../arm/../simd/intrin.h:51,
                 from ../kernel/x86_64/../arm/sum.c:33:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/avxintrin.h:517:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_extractf128_ps’: target specific option mismatch
  517 | _mm256_extractf128_ps (__m256 __X, const int __N)
      | ^~~~~~~~~~~~~~~~~~~~~
In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h:36:17: note: called from here
   36 |     __m128 hi = _mm256_extractf128_ps(sum_halves, 1);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/immintrin.h:51,
                 from ../kernel/x86_64/../arm/../simd/intrin.h:51,
                 from ../kernel/x86_64/../arm/sum.c:33:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/avxintrin.h:1454:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_castps256_ps128’: target specific option mismatch
 1454 | _mm256_castps256_ps128 (__m256 __A)
      | ^~~~~~~~~~~~~~~~~~~~~~
In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h:35:17: note: called from here
   35 |     __m128 lo = _mm256_castps256_ps128(sum_halves);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/immintrin.h:51,
                 from ../kernel/x86_64/../arm/../simd/intrin.h:51,
                 from ../kernel/x86_64/../arm/sum.c:33:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/avxintrin.h:270:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_hadd_ps’: target specific option mismatch
  270 | _mm256_hadd_ps (__m256 __X, __m256 __Y)
      | ^~~~~~~~~~~~~~
In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h:34:18: note: called from here
   34 |     sum_halves = _mm256_hadd_ps(sum_halves, sum_halves);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/immintrin.h:51,
                 from ../kernel/x86_64/../arm/../simd/intrin.h:51,
                 from ../kernel/x86_64/../arm/sum.c:33:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/avxintrin.h:270:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_hadd_ps’: target specific option mismatch
  270 | _mm256_hadd_ps (__m256 __X, __m256 __Y)
      | ^~~~~~~~~~~~~~
In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h:33:25: note: called from here
   33 |     __m256 sum_halves = _mm256_hadd_ps(a, a);
      |                         ^~~~~~~~~~~~~~~~~~~~
make[1]: *** [Makefile.L1:691: ssum_k.o] Error 1

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: 

cc -c -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DMAX_STACK_ALLOC=2048 -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=32 -DMAX_PARALLEL_NUMBER=1 -DUSE_TLS -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.11\" -msse3 -mssse3 -msse4.1 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=idmax_k -DASMFNAME=idmax_k_ -DNAME=idmax_k_ -DCNAME=idmax_k -DCHAR_NAME=\"idmax_k_\" -DCHAR_CNAME=\"idmax_k\" -DNO_AFFINITY -I.. -DDOUBLE  -UCOMPLEX -UCOMPLEX -DDOUBLE -UUSE_ABS  -UUSE_MIN ../kernel/x86_64/iamax_sse2.S -o idmax_k.o
In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h: In function ‘v_sum_f32’:
../kernel/x86_64/../arm/../simd/intrin_avx.h:31:20: note: the ABI for passing parameters with 32-byte alignment has changed in GCC 4.6
   31 | BLAS_FINLINE float v_sum_f32(__m256 a)
      |                    ^~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/immintrin.h:51,
                 from ../kernel/x86_64/../arm/../simd/intrin.h:51,
                 from ../kernel/x86_64/../arm/sum.c:33:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/avxintrin.h:517:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_extractf128_ps’: target specific option mismatch
  517 | _mm256_extractf128_ps (__m256 __X, const int __N)
      | ^~~~~~~~~~~~~~~~~~~~~
In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h:36:17: note: called from here
   36 |     __m128 hi = _mm256_extractf128_ps(sum_halves, 1);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/immintrin.h:51,
                 from ../kernel/x86_64/../arm/../simd/intrin.h:51,
                 from ../kernel/x86_64/../arm/sum.c:33:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/avxintrin.h:1454:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_castps256_ps128’: target specific option mismatch
 1454 | _mm256_castps256_ps128 (__m256 __A)
      | ^~~~~~~~~~~~~~~~~~~~~~
In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h:35:17: note: called from here
   35 |     __m128 lo = _mm256_castps256_ps128(sum_halves);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/immintrin.h:51,
                 from ../kernel/x86_64/../arm/../simd/intrin.h:51,
                 from ../kernel/x86_64/../arm/sum.c:33:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/avxintrin.h:270:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_hadd_ps’: target specific option mismatch
  270 | _mm256_hadd_ps (__m256 __X, __m256 __Y)
      | ^~~~~~~~~~~~~~
In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h:34:18: note: called from here
   34 |     sum_halves = _mm256_hadd_ps(sum_halves, sum_halves);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/immintrin.h:51,
                 from ../kernel/x86_64/../arm/../simd/intrin.h:51,
                 from ../kernel/x86_64/../arm/sum.c:33:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/avxintrin.h:270:1: error: inlining failed in call to ‘always_inline’ ‘_mm256_hadd_ps’: target specific option mismatch
  270 | _mm256_hadd_ps (__m256 __X, __m256 __Y)
      | ^~~~~~~~~~~~~~
In file included from ../kernel/x86_64/../arm/../simd/intrin.h:63,
                 from ../kernel/x86_64/../arm/sum.c:33:
../kernel/x86_64/../arm/../simd/intrin_avx.h:33:25: note: called from here
   33 |     __m256 sum_halves = _mm256_hadd_ps(a, a);
      |                         ^~~~~~~~~~~~~~~~~~~~
cc -c -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DMAX_STACK_ALLOC=2048 -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=32 -DMAX_PARALLEL_NUMBER=1 -DUSE_TLS -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.11\" -msse3 -mssse3 -msse4.1 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=idmin_k -DASMFNAME=idmin_k_ -DNAME=idmin_k_ -DCNAME=idmin_k -DCHAR_NAME=\"idmin_k_\" -DCHAR_CNAME=\"idmin_k\" -DNO_AFFINITY -I.. -DDOUBLE  -UCOMPLEX -UCOMPLEX -DDOUBLE -UUSE_ABS  -DUSE_MIN ../kernel/x86_64/iamax_sse2.S -o idmin_k.o
cc -c -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DMAX_STACK_ALLOC=2048 -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=32 -DMAX_PARALLEL_NUMBER=1 -DUSE_TLS -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.11\" -msse3 -mssse3 -msse4.1 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=dasum_k -DASMFNAME=dasum_k_ -DNAME=dasum_k_ -DCNAME=dasum_k -DCHAR_NAME=\"dasum_k_\" -DCHAR_CNAME=\"dasum_k\" -DNO_AFFINITY -I.. -DDOUBLE  -UCOMPLEX -UCOMPLEX -DDOUBLE ../kernel/x86_64/asum_sse2.S -o dasum_k.o
cc -c -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DMAX_STACK_ALLOC=2048 -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=32 -DMAX_PARALLEL_NUMBER=1 -DUSE_TLS -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.11\" -msse3 -mssse3 -msse4.1 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=daxpy_k -DASMFNAME=daxpy_k_ -DNAME=daxpy_k_ -DCNAME=daxpy_k -DCHAR_NAME=\"daxpy_k_\" -DCHAR_CNAME=\"daxpy_k\" -DNO_AFFINITY -I.. -DDOUBLE  -UCOMPLEX -UCOMPLEX -DDOUBLE ../kernel/x86_64/daxpy.c -o daxpy_k.o
make[1]: *** [Makefile.L1:691: ssum_k.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/damir/.cache/yay/openblas-lapack/src/OpenBLAS-0.3.11/kernel'
make: *** [Makefile:165: libs] Error 1
==> ERROR: A failure occurred in build().
    Aborting...
error making: openblas-lapack

haawda commented on 2020-10-20 19:54 (UTC)

Upstream notes for version 0.3.11:

NOTE there appear to be several defects in this version unfortunately - this should not be redistributed or used in a production environment

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 suppose openblas-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, and BUILD_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 its arch 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)

I know, OMP_NUM_THREADS has the same effect. But I am getting slightly better performance when I compile without multithreading. Probably because it reduces overhead.

adfjjv commented on 2017-10-08 09:27 (UTC)

@MaartenBaert If you're using OpenBlas in a multi-threaded application the simplest thing is to disable threading by setting environment variable OPENBLAS_NUM_THREADS to 1. No need to recompile. See FAQ: https://github.com/xianyi/OpenBLAS/wiki/faq#multi-threaded

MaartenBaert commented on 2017-10-07 03:15 (UTC) (edited on 2017-10-07 03:20 (UTC) by MaartenBaert)

Actually it seems to be more complicated than this. I managed to fix the problem this way on another machine (running CentOS 6), but the same change doesn't work on this machine. CHOLMOD always launches 3 threads even with OMP_NUM_THREADS=1. On my Arch machine, OpenBLAS launches 3 extra threads and the performance crashes. On the CentOS 6 machine however, OpenBLAS launches 4 extra threads and the performance is only slightly degraded. Both machines have 4 physical cores. Looks like I still don't fully understand it. So far I'm getting the best performance with multithreading completely disabled, i.e. USE_OPENMP=0 USE_THREAD=0. This still gives me multithreading in CHOLMOD but it solves the problem, and apparently also reduces overhead slightly. EDIT: After recompiling yet another time with USE_OPENMP=1 (USE_THREAD not defined), the problem is solved on the Arch machine as well. The behaviour is now the same as on the CentOS 6 machine: 3 threads from CHOLMOD, 4 extra threads from OpenBLAS. Performance is still better with multithreading completely disabled, but at least it is usable now.

MaartenBaert commented on 2017-10-07 02:29 (UTC)

I found the problem. The issue here is USE_OPENMP=0 USE_THREAD=1. CHOLMOD uses OpenMP, and this is creating a conflict with the non-OpenMP based multithreading in this OpenBLAS package. My CPU has 4 physical cores, so OpenMP would normally create 3 worker threads to occupy the remaining cores. Instead I'm seeing 6 worker threads: 3 with 100% CPU usage (from OpenMP) and 3 with 25% CPU usage (from CHOLMOD). Breaking with a debugger attached at random times suggests that these workers are mostly just busy-waiting, wasting CPU time without doing real computation. The OpenMP threads use spinlocks, which is a terrible idea when you have more threads than physical cores. I tried testing again with OMP_WAIT_POLICY=PASSIVE (which disables the spinlocks), this results in performance comparable to the OpenMP-enabled package. OMP_NUM_THREADS=1 (which eliminates 3 worker threads) has a similar effect. Conclusion: if the parent application/library uses OpenMP, OpenBLAS should also be compiled with OpenMP support or the performance will be terrible.

adfjjv commented on 2017-10-05 17:12 (UTC)

@MaartenBaert What is your hardware? Did you compile the package on a different machine? The PKGBUILD looks like it doesn't create a hardware-agnostic package. I think it would need at a minimum DYNAMIC_ARCH=1.

MaartenBaert commented on 2017-10-02 02:45 (UTC)

I was comparing the performance of various BLAS/LAPACK packages (through CHOLMOD from SuiteSparse), and was surprised to find that this package is ~40 times slower than the 'openblas' package without LAPACK: blas + lapack: 10015ms openblas + lapack: 3721ms openblas-lapack: 161417ms atlas-lapack: 4232ms Does anyone know what could be causing this?

eolianoe commented on 2017-07-14 14:42 (UTC)

@solnce: building fine in an up to date clean chroot. OpenMP is not enabled in this PKGBUILD, so I do not understand why there is some references to OpenMP routines.

solnce commented on 2017-07-14 07:49 (UTC)

Building the most recent version fails for me. gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -O2 -DMAX_STACK_ALLOC=2048 -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=12 -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -DNO_AFFINITY -I. -O2 -DMAX_STACK_ALLOC=2048 -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DNO_WARMUP -DMAX_CPU_NUMBER=12 -DASMNAME= -DASMFNAME=_ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -DNO_AFFINITY -I.. -Wl,-O1,--sort-common,--as-needed,-z,relro -w -o linktest linktest.c ../libopenblas_nehalemp-r0.2.19.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../.. -lgfortran -lm -lquadmath -lm -lc && echo OK. ../libopenblas_nehalemp-r0.2.19.so: undefined reference to `GOMP_parallel' ../libopenblas_nehalemp-r0.2.19.so: undefined reference to `omp_in_parallel' ../libopenblas_nehalemp-r0.2.19.so: undefined reference to `omp_set_num_threads' ../libopenblas_nehalemp-r0.2.19.so: undefined reference to `omp_get_num_threads' ../libopenblas_nehalemp-r0.2.19.so: undefined reference to `omp_get_max_threads' ../libopenblas_nehalemp-r0.2.19.so: undefined reference to `omp_get_thread_num' collect2: Fehler: ld gab 1 als Ende-Status zurück

richli commented on 2017-07-13 19:00 (UTC)

Could you add another symlink? ln -sf libopenblas.so libcblas.so.${_lapackver:0:1} Otherwise, it seems a recent update to python-numpy fails: $ python -c 'import numpy' Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/numpy/core/__init__.py", line 16, in <module> from . import multiarray ImportError: libcblas.so.3: cannot open shared object file: No such file or directory

eolianoe commented on 2017-07-10 17:26 (UTC)

@xyproto: I'm fine with the move to [community] but if I'm not wrong some optimisations depend on the type of the CPU, not as strongly as atlas does but it may decrease the performance.

xyproto commented on 2017-07-10 16:15 (UTC)

@eolianoe I'm considering adopting+moving openblac-lapack to [community], making it an official package, if you're fine with it.

marcs commented on 2017-07-06 10:19 (UTC) (edited on 2017-07-06 10:35 (UTC) by marcs)

My problem seems related to the new AMD CPUs based on the Zen architecture, in my case I own a R7 1700. https://github.com/xianyi/OpenBLAS/issues/1146 https://github.com/xianyi/OpenBLAS/pull/1133 Edit: Confirmed that from the git repository I can build without errors.

adfjjv commented on 2017-06-28 14:33 (UTC)

@eolianoe I'm sorry. I was using old version of gcc because I had `/opt/cuda/bin` at the start of my PATH.

eolianoe commented on 2017-06-26 14:05 (UTC)

@adfjjv: libgfortran.so.3 comes from a previous version of gcc/gfortran and you need to rebuild each package that depends on the old version of the library. To be sure that everything is properly linked, clean the build directory and rebuild the packages that depends on libgfortran.so.3.

adfjjv commented on 2017-06-24 05:30 (UTC) (edited on 2017-06-24 05:30 (UTC) by adfjjv)

@eolianoe rebuild which package? I am building openblas-lapack (on 2 different arch machines). Maybe you can help point me to reasons why the build script thinks I have libgfortran.so.3 instead of libgfortran.so.4

eolianoe commented on 2017-06-23 20:10 (UTC)

@adfjjv: you just need to rebuild the package in order to link with the new library.

adfjjv commented on 2017-06-23 17:04 (UTC)

Error: /usr/bin/ld: warning: libgfortran.so.3, needed by ../libopenblas_haswellp-r0.2.19.so, not found I have /usr/lib/libgfortran.so.4

eolianoe commented on 2017-06-23 12:49 (UTC)

@marcs: it seems that your build is failing with the first file (getarch_2nd.c) and then there are errors because some variables are not defined. I've no idea why it is failing, you may try to build using only one CPU (add MAKE_NB_JOBS=1 in the _config variable in the PKGBUILD). If it's still failing you should report the issue upstream with some details, like the CPU you are using.

marcs commented on 2017-06-23 12:17 (UTC)

Log of "makepkg -L": https://pastebin.com/PHRzDQUF

eolianoe commented on 2017-06-19 09:05 (UTC)

@marcs: I tried again on a different arch machine and the compilation is going fine, would you like to send me the full log in order to see what is different?

marcs commented on 2017-06-19 07:32 (UTC)

I'm on a 64bit installation, I got the same error with both ccm32 and ccm64.

eolianoe commented on 2017-06-16 10:48 (UTC)

@marcs: I'm able to build the package with ccm64 but I'm getting some errors with ccm32. Which architecture are you using?

marcs commented on 2017-06-16 08:48 (UTC)

I tested this package on a clean chroot (using: https://aur.archlinux.org/packages/clean-chroot-manager/) and I got the error message I've included before.

eolianoe commented on 2017-06-08 12:38 (UTC)

@marcs: I'm not getting this error even in a clean chroot, so you may have some special configurations that break the build.

marcs commented on 2017-06-08 07:59 (UTC)

I got this error message on my setup: https://pastebin.com/H2munv1x

eolianoe commented on 2017-06-03 11:32 (UTC)

@nivata: 'find_package(BLAS)' and 'find_package(LAPACK)' are working on my setup, can you provide the error message?

nivata commented on 2017-06-02 17:10 (UTC)

It seems that 'find_package(BLAS)` no longer works with cmake 3.8.0 and this package. However the `FindBLAS.cmake` says that OpenBLAS is supported. Can we do something about it?

eolianoe commented on 2017-06-01 14:34 (UTC) (edited on 2017-06-01 14:35 (UTC) by eolianoe)

@dbermond & @flying-sheep: done in 0.2.19-2. The pkgrel bump is not really mandatory you can just rebuild the package on your own.

dbermond commented on 2017-05-29 21:35 (UTC)

@eolianoe Package needs a rebuild against the newly released gcc-libs 7.1.1 (libgfortran.so.4). Please, update $pkgrel.

eolianoe commented on 2017-04-29 15:48 (UTC)

@ewtoombs: could you find which flags make the build fails?

ewtoombs commented on 2017-04-28 21:56 (UTC) (edited on 2017-04-28 22:02 (UTC) by ewtoombs)

This PKGBUILD (version 0.2.19-1 at the time of writing this) isn't working for my CPU (an Intel Wolfdale-3M), and probably many others. I'm getting illegal instruction errors from some kernels calling femms. I fixed it by nuking the CFLAGS. That's what https://aur.archlinux.org/packages/openblas-lapack-git does. For maximum compatibility, that's what this PKGBUILD should do too. My modifications: ``` build(){ cd "${srcdir}/${_PkgName}-${pkgver}" unset CFLAGS #<--- unset CXXFLAGS #<--- make ${_config} libs netlib shared } ```

Fandekasp commented on 2017-02-22 05:11 (UTC)

Got an error "OpenBLAS: Detecting CPU failed" on xps 13 Following https://github.com/xianyi/OpenBLAS/issues/983, and searching https://github.com/xianyi/OpenBLAS/blob/develop/cpuid_x86.c for my cpu target (kaby lake seems to be HASWELL) I resolved it by adding TARGET=HASWELL at the end of the make line in build()

chicomag commented on 2016-12-18 02:35 (UTC)

It builds successfully in armv7h arch, so, it's worth adding this target.

flocke commented on 2016-09-06 08:08 (UTC)

Alright, found my mistake. Rebuilding python-scipy-openblas failed because I forgot to rebuild python2-numpy-openblas and scipy also wants to build the pyton2 version in one go.

eolianoe commented on 2016-09-05 12:46 (UTC)

@flocke: I removed because it seems to be unused by the project and that it enforces the soname of the library. Now, the soname is only enforces by the compilation. You just need to rebuild the packages depending on openblas-lapack.

flocke commented on 2016-09-05 07:43 (UTC)

Any reasons why you removed the 'MAJOR_VERSION=3' part from the PKGBUILD? Anything linked against libopenblas.so.3 will fail after the update to 0.2.19 (e.g. python-scipy-openblas).

eolianoe commented on 2016-05-30 18:57 (UTC)

@buzz777: I know that there is some troubles with `USE_OPENMP=0` or `=1` depending on the application, see the comments below. If you do not like the choice in the PKGBUILD, just change it and rebuild. I do not have so much time to make full tests in various OpenMP applications, but I will try to investigate it. The README is not mine it is the one of the upstream developers, if you have trouble with it, fill a bug report upstream.

buzz777 commented on 2016-05-30 18:32 (UTC)

Changing PKGINFO to USE_OPENMP=1 still produces incorrect build of openblas, and error is still there: OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option. OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option. Please fix this or update readme with proper information on how to compile OpenBlas with OpenMP.

commented on 2016-04-30 09:47 (UTC)

I tried it with https://aur.archlinux.org/packages/python-spams-svn/ and using openmp, but still have issues of cpu and fans going while for seemingly no reason. The single threaded version works fine (and the library itself is multithreaded with openmp) so it might still have issues.

commented on 2016-04-30 05:34 (UTC)

Great, I will try enabling it on my side then to see if everything works fine. I do remember that older versions (maybe < 0.2.12 let's say) would something just hang in conflict with other openmp stuff and just deadlock there, but it should be 'fixed' (in the sense that ubuntu did backport it, but even that would still not work on my work computer), so hopefully the latest release will work on my personal laptop.

eolianoe commented on 2016-04-28 07:49 (UTC)

@berquist & @dekece: I disable it sometimes ago because I had trouble within a OpenMP application. I will make some new tests and enable it if it works fine in all configurations.

berquist commented on 2016-04-27 19:31 (UTC)

@dekece I have been using my own PKGBUILD with `USE_OPENMP=1` for quite some time and have never had any problems with it.

commented on 2016-04-27 17:41 (UTC)

I see that the pkgbuild explicitely disable openmp support and is using threads. Is there any special reason/performnace issue? Just curious, as openblas throws me "OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option." in another library, but of course I don't want to risk breaking stuff in weird ways by doing so.

anntzer commented on 2016-02-06 07:33 (UTC)

I believe this should also provide/conflicts lapacke (the C interface to LAPACK).

pavanky commented on 2015-12-30 05:44 (UTC)

You should also create symlinks for liblapacke.so considering that both the symbols and headers are part of the package.

eolianoe commented on 2015-10-07 07:22 (UTC)

I just removed the detection of cores in PKGBUILD as it seems to be correctly detected internally.

alexanderp commented on 2015-10-06 19:31 (UTC)

I have grep='grep -n' which was causing trouble with the detection of the number of cores. I replaced grep with /usr/bin/grep but it can also be replaced with "command grep" or "/usr/bin/env grep"

eolianoe commented on 2015-10-06 11:30 (UTC)

@alexanderp: I'm not in favour of such technique as it is not used in the official packages. You should rather define your aliases with another name to avoids conflicts. What aliases are you using for that can lead to errors in the PKGBUILD ?

alexanderp commented on 2015-10-05 21:00 (UTC)

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

aquarix commented on 2015-06-09 11:40 (UTC)

I had to add add "FC=gfortran" to the beginning of _config variable in the PKGBUILD in order to build the package.

Rufflewind commented on 2015-06-04 00:48 (UTC)

USE_THREAD=0, why? Doesn't that force OpenBLAS to be single-threaded?

hllowrld commented on 2015-02-26 22:28 (UTC)

I think there's a problem with the url: You want: https://github.com/xianyi/OpenBLAS/archive/v0.2.13.tar.gz but currently the build has: http://xianyi.github.com/OpenBLAS/archive/v0.2.13.tar.gz

eolianoe commented on 2015-02-25 21:47 (UTC)

Adopted, I will provide an updated PKGBUILB by the end of the week (no acces to an Arch machine for few days).

aphirst commented on 2015-02-16 13:20 (UTC)

0.2.13 has been out for a while now. :) https://github.com/xianyi/OpenBLAS/releases/tag/v0.2.13

SuperBo commented on 2015-02-02 09:24 (UTC)

:: failed to verify openblas-lapack integrity

aphirst commented on 2014-07-05 19:25 (UTC)

Ah, false alarm. I ran it again, giving it a bit more time, and eventually it did successfully complete.

aphirst commented on 2014-07-05 17:28 (UTC)

When I try to build this, I get a seemingly endless hang with 100% CPU usage at the following lines, which I think are some sort of build test: rm -f ?BLAT3.SUMM OMP_NUM_THREADS=2 ./sblat3 < ./sblat3.dat rm -f ?BLAT2.SUMM OMP_NUM_THREADS=2 ./sblat2 < ./sblat2.dat I left it running for a full hour and it never made any progress past there. So I killed those two processes, at which point makepkg quit with /bin/sh: line 1: 31772 Killed OMP_NUM_THREADS=2 ./sblat3 < ./sblat3.dat Makefile:59: recipe for target 'level3' failed make[1]: *** [level3] Error 137 make[1]: *** Waiting for unfinished jobs.... /bin/sh: line 1: 31779 Killed OMP_NUM_THREADS=2 ./sblat2 < ./sblat2.dat Makefile:26: recipe for target 'level2' failed make[1]: *** [level2] Error 137 make[1]: Leaving directory '/tmp/yaourt-tmp-adam/aur-openblas-lapack/src/OpenBLAS-0.2.9/test' Makefile:111: recipe for target 'tests' failed make: *** [tests] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build openblas-lapack. Is there something I should be doing differently, or is this known already?

sftrytry commented on 2014-06-18 05:42 (UTC)

On my PC, I tested that 2.9 is much slower, 20%~25%, than 2.8.

sftrytry commented on 2013-11-23 02:05 (UTC)

@Xyne I have updated the PKGBUILD to let it provide itself. :) There is already a discussion in openblas package. gborzi, the maitainer, prefers to keep openblas as simple as possible.

Xyne commented on 2013-11-23 01:44 (UTC)

Hi, The package should also "provide" openblas if it provides all of the same functionality (and more). Have you discussed merging your optimizations into the openblas package? Regards, Xyne

sftrytry commented on 2013-11-20 23:58 (UTC)

This package is based on gborzi's openblas. openblas does not work as "drop in" as I expected. Thus, I enabled lapack and cblas within openblas. This version works with Xiao0er's python2-numpy-openblas