| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| arm-gcc-flags.patch | Use flags suitable for armhf port when TARGET=ARMV6 See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf. Also, if we don't explicitly set the -march and -mfpu flags, the resulting static libraries crash with SIGILL (reason not yet elucidated). |
Sbastien Villemot <sebastien@debian.org> | not-needed | 2015-04-29 | ||
| kfreebsd.patch | Various fixes for kFreeBSD shared library Under kFreeBSD, give a SONAME to the shared library and install it. Also link it against libm. Simply use the same code as Linux for all these operations. |
Sbastien Villemot <sebastien@debian.org> | not-needed | 2014-08-05 | ||
| remove-openmp-warning.patch | Remove warning about OpenMP This warning is annoying when the library is built with pthreads. See #684344 |
Sbastien Villemot <sebastien@debian.org> | no | 2014-02-17 | ||
| no-embedded-lapack.patch | Adapt build system for the absence of lapack-netlib/ and relapack directories. Instead use the binary provided by package liblapack-pic, stripping from it the symbols that are overridden by OpenBLAS. |
Sbastien Villemot <sebastien@debian.org> | not-needed | 2017-07-27 | ||
| shared-blas-lapack.patch | Create shared libraries lib{blas,lapack}.so.3 * It is done so that duplicate code with libopenblas.so.0 is kept as low as possible. Only the symbols from the external BLAS/LAPACK API are incorporated in the shared libraries. The rest is obtained by dynamic linking against libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in order to differentiate it at runtime from other BLAS implementations (see #960728). The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is the one selected in the lib{blas,lapack}.so.3 alternative, and not the one selected in the libopenblas.so.0 alternative. * See also override_dh_shlibdeps in debian/rules * Also order the files when calling `ar' or $(CC), to make the build reproducible (see #824639) * Also link the shared blas and lapack against gomp (see #945791) |
Mo Zhou <lumin@debian.org> | not-needed | 2020-07-31 | ||
| matgen-symbols-not-included.patch | MATGEN symbols are not included in Debian binary The libopenblas binaries do not include libmatgen code, so don't mark them as exported and don't test for their presence (in linktest). |
Sbastien Villemot <sebastien@debian.org> | not-needed | 2016-03-24 | ||
| gensymbols-fix-detect-netlib.patch | when building libjulia-openblas64, we place the lapack shared objects under lapack64-netlib/ directory. But if exports/gensymbol cannot detect the existence of the lapack-netlib directory, it will skip the lapack symbol which results in incomplete symbol mangling (SYMBOLSUFFIX=64_) through objcopy. |
Mo Zhou | invalid | 2020-08-01 | ||
| riscv64-supported.patch | no | |||||
| fix-arm64-sigill.patch | Fix SIGILL on arm64 when HWCAP_CPUID is not set This is a crashing bug (SIGILL) that also affects numpy on arm64. One line of processors affected are NVIDIA Tegra (Jetson devices). . On ARM64, openblas uses feature registers to detect the detailed processor arch. It queries HWCAP_CPUID to check if the feature registers are used. But due to a missing volatile declaration, gcc seems to break this guarding in optimization. |
no | debian | upstream, https://github.com/xianyi/OpenBLAS/commit/6fe0f1fab9d6a7f46d71d37ebb210fbf56924fbc | 2021-04-18 | |
| avx512-dgemm.patch | Fix incorrect results of AVX512 DGEMM kernel when built on pre-AVX2 machine When building OpenBLAS with dynamic arch selection on x86-64 hardware that does not support AVX2 (e.g. Intel Ivybridge or earlier), then the AVX512 (SkylakeX) kernel for DGEMM would produce incorrect results (of course when run on AVX512-capable hardware). . The problem was that the check for determining whether the compiler is able to understand AVX512 assembly/intrinsics was doubly incorrect: it would test the build machine capabilities (instead of the compiler capabilities); and it would check for AVX2 instead of AVX512. As a consequence, on pre-AVX2 hardware, the build system would conclude that the compiler is not able to understand AVX512 primitives, and would create a broken AVX512 (SkylakeX) DGEMM kernel (essentially a Haswell kernel, but with some wrong assumptions, hence leading to incorrect numerical results). https://github.com/xianyi/OpenBLAS/issues/3454 https://github.com/xianyi/OpenBLAS/issues/3557 |
yes | debian upstream | upstream, https://github.com/xianyi/OpenBLAS/pull/3579 | 2023-06-26 |