NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
143635b0c3
kumquat-buildroot/package/openblas/openblas.mk

80 lines
2.3 KiB
Makefile
Raw Normal View History

openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
################################################################################
#
# openblas
#
################################################################################
package/openblas: bump version to 0.3.9 Changelog: http://www.openblas.net/Changelog.txt Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-04-12 16:43:07 +02:00
OPENBLAS_VERSION = 0.3.9
package: remove 'v' prefix from github-fetched packages On Github, a large number of projects name their tag vXYZ (i.e v3.0, v0.1, etc.). In some packages we do: <pkg>_VERSION = v0.3 <pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION)) And in some other packages we do: <pkg>_VERSION = 0.3 <pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION)) I.e in one case we consider the version to be v0.3, in the other case we consider 0.3 to be the version. The problem with v0.3 is that when used in conjunction with release-monitoring.org, it doesn't work very well, because release-monitoring.org has the concept of "version prefix" and using that they drop the "v" prefix for the version. Therefore, a number of packages in Buildroot have a version that doesn't match with release-monitoring.org because Buildroot has 'v0.3' and release-monitoring.org has '0.3'. Since really the version number of 0.3, is makes sense to update our packages to drop this 'v'. This commit only addresses the (common) case of github packages where the prefix is simply 'v'. Other cases will be handled by separate commits. Also, there are a few cases that couldn't be handled mechanically that aren't covered by this commit. Signed-off-by: Victor Huesca <victor.huesca@bootlin.com> [Arnout: don't change flatbuffers, json-for-modern-cpp, libpagekite, python-scapy3k, softether] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-06-12 08:42:06 +02:00
OPENBLAS_SITE = $(call github,xianyi,OpenBLAS,v$(OPENBLAS_VERSION))
boot, package: use SPDX short identifier for BSD-3c We want to use SPDX identifier for license string as much as possible. SPDX short identifier for BSD-3c is BSD-3-Clause. This change is done using following command. find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/BSD-3c/BSD-3-Clause/g' Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-30 15:43:38 +02:00
OPENBLAS_LICENSE = BSD-3-Clause
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
OPENBLAS_LICENSE_FILES = LICENSE
OPENBLAS_INSTALL_STAGING = YES
# Initialise OpenBLAS make options to $(TARGET_CONFIGURE_OPTS)
OPENBLAS_MAKE_OPTS = $(TARGET_CONFIGURE_OPTS)
# Enable cross-compiling
OPENBLAS_MAKE_OPTS += CROSS=1
# Set OpenBLAS target
OPENBLAS_MAKE_OPTS += TARGET=$(BR2_PACKAGE_OPENBLAS_TARGET)
openblas: pass ONLY_CBLAS=1 only when Fortran is not available Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-04 17:22:59 +02:00
# When Fortran is not available, only build the C version of BLAS
ifeq ($(BR2_TOOLCHAIN_HAS_FORTRAN),)
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
OPENBLAS_MAKE_OPTS += ONLY_CBLAS=1
openblas: pass ONLY_CBLAS=1 only when Fortran is not available Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-04 17:22:59 +02:00
endif
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
# Enable/Disable multi-threading (not for static-only since it uses dlfcn.h)
package/openblas: allow disabling multithreading Buildroot would automatically enable multithreading in OpenBLAS if the architecture supports it. However, one may want to avoid OpenBLAS creating threads itself and configure single-threaded operation. To accommodate this use case, add a config option for multithreading. When multithreading is disabled but OpenBLAS functions are called in the same application by multiple threads, then locking is mandatory. The USE_LOCKING flag was added in version 0.3.7 with following release note: a new option USE_LOCKING was added to ensure thread safety when OpenBLAS itself is built without multithreading but will be called from multiple threads. However, if one knows that OpenBLAS will only be called from single-threaded applications, then passing USE_LOCKING is not necessary, so make it a config option too. When multithreading is enabled, locking is implicitly enabled inside openblas, so only provide the locking option when multithreading is disabled. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-02-12 10:15:09 +01:00
ifeq ($(BR2_PACKAGE_OPENBLAS_USE_THREAD),y)
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
OPENBLAS_MAKE_OPTS += USE_THREAD=1
else
OPENBLAS_MAKE_OPTS += USE_THREAD=0
endif
package/openblas: allow disabling multithreading Buildroot would automatically enable multithreading in OpenBLAS if the architecture supports it. However, one may want to avoid OpenBLAS creating threads itself and configure single-threaded operation. To accommodate this use case, add a config option for multithreading. When multithreading is disabled but OpenBLAS functions are called in the same application by multiple threads, then locking is mandatory. The USE_LOCKING flag was added in version 0.3.7 with following release note: a new option USE_LOCKING was added to ensure thread safety when OpenBLAS itself is built without multithreading but will be called from multiple threads. However, if one knows that OpenBLAS will only be called from single-threaded applications, then passing USE_LOCKING is not necessary, so make it a config option too. When multithreading is enabled, locking is implicitly enabled inside openblas, so only provide the locking option when multithreading is disabled. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-02-12 10:15:09 +01:00
ifeq ($(BR2_PACKAGE_OPENBLAS_USE_LOCKING),y)
OPENBLAS_MAKE_OPTS += USE_LOCKING=1
else
# not passing USE_LOCKING=0 as this could be confusing: its effect is implicit
# in case of USE_THREAD=1.
endif
openblas: disable OpenMP For powerpc (and powerpc only), the openblas build system will enable USE_OPENMP when threads are enabled. But the toolchain wasn't necessarily built with OpenMP support. So explicitly disable OpenMP - for all architectures, not just powerpc, just to keep things simple. We could have autodetected whether OpenMP is available at configure time, but that would be more of a feature patch, it's up to upstream to do that. Fixes: http://autobuild.buildroot.net/results/423b5e79cd4342d6c160ed478054b294b0826c6a http://autobuild.buildroot.net/results/c9e554c8f880b49b3c9203725ac5e6565b7e5c6f Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-20 17:04:41 +01:00
# We don't know if OpenMP is available or not, so disable
OPENBLAS_MAKE_OPTS += USE_OPENMP=0
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
# Static-only/Shared-only toggle
ifeq ($(BR2_STATIC_LIBS),y)
OPENBLAS_MAKE_OPTS += NO_SHARED=1
else ifeq ($(BR2_SHARED_LIBS),y)
OPENBLAS_MAKE_OPTS += NO_STATIC=1
endif
openblas: fix build with old binutils versions Older toolchains that use binutils <= 2.23.2 are affected by binutils bug #14887 (https://sourceware.org/bugzilla/show_bug.cgi?id=14887), where: someinstruction [ foo, something ] is not accepted, due to the whitespace after [ and before ], causing the following build failures for OpenBLAS: ARM register expected -- `pld [ r1,#512 ]' Since we don't have any mechanism to add dependencies on binutils versions, we work around this problem by patching the code to remove the problematic whitespaces. As there are many many instances of this in the ARM assembly code of OpenBLAS, we use a sed expression to make this modification rather than a patch. Fixes: http://autobuild.buildroot.net/results/43e50b480b4aea0fdec745d7875c85377c114cac/ [Peter: use single quotes in sed invocation] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-20 14:36:01 +02:00
# binutils version <= 2.23.2 has a bug
# (https://sourceware.org/bugzilla/show_bug.cgi?id=14887) where
# whitespaces in ARM register specifications such as [ r1, #12 ] or [
# r2 ] cause the assembler to reject the code. Since there are
# numerous instances of such cases in the code, we use sed rather than
# a patch. We simply replace [ foobar ] by [foobar] to work around the
# problem.
define OPENBLAS_FIXUP_ARM_ASSEMBLY
$(SED) 's%\[\s*%\[%;s%\s*\]%\]%' $(@D)/kernel/arm/*.S
endef
OPENBLAS_POST_PATCH_HOOKS += OPENBLAS_FIXUP_ARM_ASSEMBLY
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
define OPENBLAS_BUILD_CMDS
$(TARGET_MAKE_ENV) $(MAKE) $(OPENBLAS_MAKE_OPTS) \
-C $(@D)
endef
define OPENBLAS_INSTALL_STAGING_CMDS
$(TARGET_MAKE_ENV) $(MAKE) $(OPENBLAS_MAKE_OPTS) \
-C $(@D) install PREFIX=$(STAGING_DIR)/usr
endef
define OPENBLAS_INSTALL_TARGET_CMDS
$(TARGET_MAKE_ENV) $(MAKE) $(OPENBLAS_MAKE_OPTS) \
-C $(@D) install PREFIX=$(TARGET_DIR)/usr
endef
$(eval $(generic-package))
Reference in New Issue Copy Permalink