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>
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>
Remove third patch (already in version)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
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>
If BR2_PACKAGE_LAPACK is enabled (without BR2_PACKAGE_CLAPACK), build of
python-numpy will fail if lapack is built before python-numpy because
lapack does not provide blas library
So disable BLAS and LAPACK through PYTHON_NUMPTY_ENV if
BR2_PACKAGE_CLAPACK is not set
Fixes:
- http://autobuild.buildroot.org/results/41671976c7be7883f31ee5f51ca0eb90b81262fd
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
host-python-numpy is required by piglit buildsystem for crosscompiling.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
LICENSE.txt sha256 is wrong. After version bumping from 1.13.3 to 1.15.1
LICENSE.txt sha256 has not be re-calculated.
New LICENSE.txt lists licenses for bundled libraries:
- Numpydoc -> 2-clause BSD
- scipy-sphinx-theme -> 3-clause BSD, PSF and Apache 2.0
- lapack-lite -> 3-clause BSD
- tempita -> BSD derived
- dragon4 -> specific to library, need to refer to dragon4.c file
Update sha256 recalculating it locally.
Fixes:
http://autobuild.buildroot.net/results/08e/08e1121af151c65b2333e06839256eb13f4ad800//http://autobuild.buildroot.net/results/9d0/9d0e557c5946b76aa4c8c87b7616433c16b61e20//
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Building python-numpy on ARC HS with glibc fails due to missing FE_*
definitions in <fenv.h>. Therefore, python-numpy is only available on
ARC HS with a C library other than glibc.
Fixes:
http://autobuild.buildroot.net/results/6b9a3310bb4f8c1fd7db0ef4476458b3eec2bf2e/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This package fails when building for ARCompact due to toolchain issue.
Marking this with special comment "#ARC toolchain issues for
ARCompact" as the package is to be enabled as soon as the issue with
the ARC toolchain is resolved.
Fixes:
http://autobuild.buildroot.net/results/4c4eaa90335756448007ae3c5ae3839fb17d4442/
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: arc-buildroot@synopsys.com
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Current BR2_PACKAGE_PYTHON_NUMPY_ARCH_SUPPORTS variable layout going
to be inconvenient and ugly for adding new architectures or
restricting specific architectures. Lets reformat layout of this
variable.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: arc-buildroot@synopsys.com
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This enables support for ARC cores in numpy.
Cherry-picked from
8edd610ffa
Hopefully becomes a part of the next major release (like 1.14).
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
With update of Numpy to the latest version we've got one change which
breaks Numpy compilcation in some cases.
This change back-ports upstream fix from:
https://github.com/numpy/numpy/pull/9740
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Cc: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Note previously used location for releases on SourceForge is no longer
supported (latest tarball v1.11.2 available there is dated 2016-10-04)
so as other distros
(see, Fedora http://pkgs.fedoraproject.org/cgit/rpms/numpy.git/tree/numpy.spec?id=7013948f8ba073c69a91a545f0a0898cb62652fa#n22)
we get release tarball directly from GitHub.
Also note 0001-no-fenv-on-uclibc.patch was rebased on v1.13.1.
0002-Don-t-blindly-enable-frexpl-and-ldexpl-for-uClibc.patch is no
longer needed. Since https://github.com/numpy/numpy/pull/4852, there
is a wrapper for frexpl and ldexpl like for the other math functions.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Cc: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Arnout: improve explanation of 0002-Don-t-blindly-enable-frexpl-and-ldexpl-for-uClibc.patch]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
Autogenerated from rename-patch.py (http://patchwork.ozlabs.org/patch/403345)
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since SourceForge sometimes serves us faulty tarballs, we can tons of
autobuild failures:
http://autobuild.buildroot.org/results/9fb/9fba5bf086a4e7a29e5f7156ec43847db7aacfc4/http://autobuild.buildroot.org/results/6c8/6c837b244c45ac3b3a887734a371cd6d226cf216/
...
Fix that by adding hash files for all SourceForge-hosted packages (thos
etht did not already have it).
We normally prefer to use hashes published by upstream, but hunting them
all one by one is a tedious task, so those hashes were all locally
computed with a script that searched for SF-hosted packages, downloades
the associated tarball, computed the hash, and stored it in the
corresponding .hash file.
Also, SF publishes sha1 hashes, while I used the stronger sha256, since
sha1 is now considered to be relatively weak.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Richard Braun <rbraun@sceen.net>
Cc: Nathaniel Roach <nroach44@gmail.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>
The numpy/core/include/numpy/npy_cpu.h file has some
architecture-specific definitions, and not all architectures are
supported. This commit makes sure python-numpy cannot be selected on
the architectures that are not supported.
Fixes:
http://autobuild.buildroot.org/results/327/327c85f5b1849d390fcf0727cf48e621b946571f/
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>
