With a C library which does not provide fenv.h, it won't work at runtime:
Crash after an "import numpy" on python.
Since numpy v1.16.0:
"Alpine Linux (and other musl c library distros) support
We now default to use fenv.h for floating point status error reporting.
Previously we had a broken default that sometimes would not report
underflow, overflow, and invalid floating point operations. Now we can
support non-glibc distrubutions like Alpine Linux as long as they ship
fenv.h."
Disable python-numpy for uClibc to avoid the runtime errors.
ARC's glibc used to have an incomplete fenv.h, but this has been fixed
since commit be0aaaaecd ("toolchain: bump ARC tools to arc-2019.03
release"), so we don't need an exception for ARC.
Two patches attempted to fix the build for uclibc and glibc for ARC, but
didn't fix the runtime issue. Remove those patches.
Signed-off-by: Damien DUVAL <damien.duval@smile.fr>
Signed-off-by: Alexandre PAYEN <alexandre.payen@smile.fr>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit 1aa59097e6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The numpy build system attempts to find lapack/blas at build time. It
tries a lot of different implementations, e.g. lapack, openblas, atlas,
... It is possible to help this automatic discovery by specifying
libraries to load in site.cfg and/or by setting environment variables
BLAS and LAPACK.
Unfortunately, the build system's logic is really hard to understand and
it's fragile. For example, regardless of what is specified as libraries
to load, it *will* try to find libblas.so and liblapack.so. However,
when something is specified explicitly in site.cfg, it will use a
different code path.
It turns out that when we specified the blas and lapack libraries
explicitly, as is done now, the build system logic will assume (without
checking) that cblas is used. This causes calls to cblas_* to be linked
in - again without checking, because numpy contains a copy of the header
and it uses dlopen to load it. clapack, however, does *not* provide
cblas (although it does provide a library libblas.so, but no
libcblas.so). Therefore, when importing numpy at runtime, we get an
error like:
ImportError: /usr/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-arm-linux-gnueabihf.so: undefined symbol: cblas_sgemm
The initial attempt to fix this added cblas to the libraries. This
happens to work because apparently the entire libraries line is ignored
when a non-existing library is added to it (remember, clapack does not
provide libcblas).
Another attempt was to set BLAS=None in the environment. This didn't
have any effect. Setting both BLAS=None and LAPACK=None does disable
lapack and blas, but then we don't use clapack at all.
In fact, it is not necessary to provide a libraries line at all: the
build system will attempt to find liblapack, libblas and libcblas
without any help.
Therefore, remove the libraries line from site.cfg and remove
PYTHON_NUMPY_SITE_CFG_LIBS.
Note that the paths to staging's /usr/include and /usr/lib need to be
specified explicitly. Indeed, the numpy build system doesn't use the
compiler to check the presence/absence of includes and libraries; it
searches the paths itself. It also hardcodes paths to /usr/lib etc, but
this is something that will be tackled in a separate commit.
Note that there is another problem: both lapack and clapack provide
libblas.so and liblapack.so. This will be handled in a later commit.
Also, openblas provides a cblas implementation in libopenblas.so, so
there should be a dependency on openblas to make sure numpy can find it.
This part is not entirely clear yet, so it will also be handled in a
separate commit.
Runtime testing is essential to be able to track this kind of issue, so
that is something that will be added in a separate commit as well.
Fixes:
http://lists.busybox.net/pipermail/buildroot/2019-June/252380.html
Initial patch from Giulio Benetti :
[v1] http://patchwork.ozlabs.org/patch/1100100/
[v2] http://patchwork.ozlabs.org/patch/1100208/
Signed-off-by: Alexandre PAYEN <alexandre.payen@smile.fr>
Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit 4c2b6978f6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Release 1.16.2 tarball doesn't contain all sublibraries license files
listed in the base LICENSE.txt file, one is missing, even though it is
present in the project Git repository.
This makes python-numpy-legal-info incomplete.
- Add patch to add missing sublibrary license file:
numpy/linalg/lapack_lite/LICENSE.txt
- its sha256 into hash file.
- update PYTHON_NUMPY_LICENSE adding:
BSD-2-Clause, PSF, Apache-2.0, MIT, Zlib
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Update patches and send them upstream
- Update license hash (typos fixed and year updated)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Building python-numpy on ARC with glibc fails due to missing FE_*
definitions in <fenv.h>. These exceptions are not supported by
ARC architecture. Let's add patch, which disables compilation
of a part of the code in which FE_* errors occur for ARC.
ARCompact toolchain issues are already fixed in the latest toolchain.
Also since commit "311af5e8c2db887800639bc803c8201b6b70e9ce"
("toolchain/toolchain-buildroot: enable glibc for all little-endian
ARCs with atomic ops") glibc is available for ARCompact.
That is why in Config.in we are leaving only "BR_arc" and
removing comments, which are not actual.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is just a bug-fix release.
Removing 0003-BUG-Ensure-_npy_scaled_cexp-f-l-is-defined-when-need.patch
as it is a part of the release.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
Some packages selects python-numpy. This package has a some CPU specific
code. To simplify and avoid duplicate dependencies this patch introduce an
hidden ARCH_SUPPORTS variable.
[Thomas: fix the definition of the new option to make sure its value
is actually 'y' when a supported architecture is used.]
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It turns out that uClibc only enables the long double math functions
for some architectures (god know why, so what if long double is the
same as double, these functions should still be defined). Since
python-numpy links with those functions, the module will fail to load
on ARM, MIPS and SH.
However, python-numpy actually checks for each function if it is really
available. Only, it overrides that check for ldexpl and frexpl when
long double is the same as double (i.e. in exactly the case the uClibc
doesn't have these functions).
So add another exception for this.
Upstream-status: not applicable (code has changed too much)
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit b0f025386f a patch was added
to make sure that python-numpy does work in uClibc. This patch was
needed for the x86 architecture, because uClibc in fact does support
fenv for x86. However, we don't turn on this support in our uClibc
config. Because the Config.in depends still allowed uClibc for x86,
this lead to a built failure, which lead to the fix in commit b0f02538.
But since this fix also fixes it for all other (supported)
architectures, we can just remove the !uClibc dependency completely.
This is also propagated to the reverse dependency in opencv3.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_BUILD_OPT.
Sed command used:
find * -type f | xargs sed -i 's#_BUILD_OPT\>#&S#g'
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
python-numpy can be linked with libblas and liblapack, so
automatically do it when clapack is enabled.
[Thomas:
- Fix issues in the original submission and reformat according to
Yann E. Morin suggestions.
- Properly format the "libraries" entry in site.cfg as outlined in
the example site.cfg file: the list of libraries should be
space-separated.]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch add NumPy package for python.
Since Fortran support has been deprecated in Buildroot since the 2013.11
release, and because most of the external toolchains do not provide a
Fortran compiler, it is necessary to explicity disable Fortran compiler
to avoid catching the one from the host system if any.
We also need to fill a site.cfg file to tell NumPy build-system where
it should looking for BLAS and LAPACK libraries.
Some packages may include headers provided by python-numpy package, so
python-numpy is installed to the staging directory.
[Thomas:
- add dependency in Config.in to take into account fenv.h
requirement, suggested by Yann E. Morin.
- modified to use the staging installation logic in the python
package infrastructure.]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
