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>
This commit fixes several build issues of OpenBLAS on ARM:
- The first one occured on ARMv5 platforms, when the ARMV5 OpenBLAS
architecture is used. In this case, OpenBLAS build system forces
-march=armv5, which may not be correct for certain toolchains. As an
example, the Sourcery CodeBench toolchain has an ARMv4 and an ARMv5
sysroot. The ARMv5 sysroot is actually an armv5te sysroot, so when
OpenBLAS forces -march=armv5, gcc thinks it should use the ARMv4
sysroot, causing build failures.
To address this, a patch to completely remove the -march ARM CFLAGS
is added to OpenBLAS.
Fixes:
http://autobuild.buildroot.net/results/991497b12b70f948169e5ad99eebd0fe7f6209a2/
- The second one occured on ARMv7 platforms, when the ARMV7 OpenBLAS
architecture is used. The OpenBLAS code expects an EABIhf build, so a
dependency is added for EABIhf for both ARMv6 and ARMv7.
Fixes:
http://autobuild.buildroot.net/results/0ba0bee48a83367fcefab827e8eaa72f0c8fe90b/
- Once the previous ARMv7 problem has been fixed, it turns out that the
ARMv7 specific code in OpenBLAS contains VFPv3 specific
code. Therefore, the user *must* have choosen either VFPv3 or VFPv4,
or the code will not build. VFPv3-D16/VFPv4-D16 are not sufficient,
as more than 16 registers are used by the OpenBLAS code.
To address this, the ARMV7 platform of OpenBLAS is restricted to the
proper VFPv3/VFPv4 selection, and the ARMV6 platform is restricted to
the proper VFPv2 selection.
This problem was not visible in the autobuilders, as it was hidden by
the previous one.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>