This layer contains a recipe for building Scipy 1.3.3 as well as a series of
patches and bbappend files necessary to build the recipe.
Simply clone this repository as a new layer in your workspace:
git clone https://github.com/gpanders/meta-scipy meta-scipy
bitbake-layers add-layer meta-scipy
This repository serves as a community hub for a full OpenEmbedded Scipy solution. If you're able to get Scipy working for your platform or application, please consider contributing your changes. You can also update the wiki, which is publicly editable.
Contributions should be well-tested and should adhere to the OpenEmbedded style guide.
This layer depends on:
The recipe was tested using the warrior branch in all upstream layers
(including the poky reference distribution). YMMV with other versions.
To enable FORTRAN support, append the following lines to your local.conf file:
FORTRAN_forcevariable = ",fortran"
RUNTIMETARGET_append_pn-gcc-runtime = " libquadmath"
If you're using a custom distribution, you can alternatively include those two
lines in your distro.conf file.
By default, Scipy requires a CBLAS implementation of the BLAS library (it
attempts to link against cblas_ versions of BLAS methods). The lapack recipe
included in the meta-oe layer is able to build the CBLAS library
by setting the CBLAS=ON CMake parameter. This is done in the
lapack_%.bbappend file.
Unfortunately, setting CBLAS=ON in the lapack recipe causes other errors
when building LAPACK. In particular, the LAPACK CMake build process has a step
to ensure that the provided Fortran and C compilers are compatible with each
other. This step had an unknown bug when performed in a cross-compiling
context which has now been addressed upstream. The patch for that fix is
included in the cmake-native_%.bbappend file in this repository.
The two above fixes allow Scipy to compile, but Yocto will still complain when
Scipy is packaged because the shared objects are linked using the -rpath
flag, which provides a runtime path to the binary to instruct the loader where
to look for other libraries at runtime. However, the paths provided are paths
on the build machine, not on the target machine, which Yocto (correctly)
detects and warns you about.
In our case, all of our libraries are in the standard library locations
(/usr/lib) on the target, so there is no need to include runtime path
information in the shared object files. Unfortunately, there is no way to
inform numpy to not use runtime library paths when linking. The patch
in python3-numpy_%.bbappend forces numpy to disable runtime paths when
cross-compiling libraries using numpy.distutils.
NOTE that this is not really a good solution and is simply a hack. It is possible that this patch may break other recipes.