Package Details: python-scipy-mkl 1.0.0-2

Git Clone URL: https://aur.archlinux.org/python-scipy-mkl.git (read-only)
Package Base: python-scipy-mkl
Description: SciPy is open-source software for mathematics, science, and engineering.
Upstream URL: http://www.scipy.org/
Licenses: BSD
Conflicts: python-scipy
Provides: python-scipy=${pkgver}, python3-scipy=${pkgver}, scipy=${pkgver}
Replaces: python-scipy
Submitter: bred
Maintainer: bred
Last Packager: bred
Votes: 15
Popularity: 0.028351
First Submitted: 2012-09-06 19:34
Last Updated: 2017-11-07 19:25

Required by (146)

Sources (3)

Latest Comments

hcb commented on 2017-12-04 09:57

Replacing .. with ${srcdir} worked for me:

# copy python3 build files
cp ${srcdir}/build_python3.sh scipy-${pkgver}

# copy python2 build files
cp -r scipy-${pkgver} scipy-${pkgver}-py2
cp ${srcdir}/build_python2.sh scipy-${pkgver}-py2

gwaterst commented on 2017-11-08 15:09

Yes, it probably is the BUILDDIR variable that changes the behaviour.

According to the documentation a proper solution would be to put the copy processes into a prepare() section and use $srcdir as target folder:

prepare() {
# copy python3 build files
cp build_python3.sh $srcdir/scipy-${pkgver}

# copy python2 build files
cp -r $srcdir/scipy-${pkgver} srcdir/scipy-${pkgver}-py2
cp build_python2.sh $srcdir/scipy-${pkgver}-py2
}

An alternative would be to use the $startdir variable instead of '../'

arvidsaur commented on 2017-11-08 14:01

@gwatterst well that did not work for me, could it be because I have set "BUILDDIR=/tmp/makepkg" ? this is the first pkgbuild that has failed for me with that setting, removing "../" worked for me.

gwaterst commented on 2017-11-08 12:39

@arvidsaur:
No, that should be correct, since "makepkg will change the current directory to $srcdir before executing the build()" (from the wiki page).

So, during build() we already are in src/ and the 2 shell scripts are still in ../

However, one might consider copying all the files during prepare()

arvidsaur commented on 2017-11-08 07:28

I think there is a minor error in the PKGBUILD it should be
"cp build_python3.sh scipy-${pkgver}" instead of "cp ../build_python3.sh scipy-${pkgver}" same for the python2 file.


bred commented on 2017-11-07 19:26

Now it works also with icc.
Thanks to all for the suggestions and the PKGBUILD !!!


gwaterst commented on 2017-11-07 09:42

I can confirm the hack of invik is working. The problem appears to be that the C sources need the set environment variable while compiling the C++ sources with the set environment variables returns an error.

I have outsourced the ever-repeating builds into a shell script that make it possible to build the package with a single makepkg command.

I'll send this version the the package maintainer.

invik commented on 2017-11-05 19:18

There is a very dumb hack to get the package to compile with the 2018 Intel compiler (the one with the _Float128 error): loop-compile 8 or 10 times (sorry, lost count), one prepending the '__INTEL_PRE_CFLAGS="$__INTEL_PRE_CFLAGS -D_Float128=__float128"' variable, one without. I.e.:

__INTEL_PRE_CFLAGS=" -D_Float128=__float128" python3 setup.py config --compiler=intelem --fcompiler=intelem build_clib --compiler=intelem --fcompiler=intelem build_ext --compiler=intelem --fcompiler=intelem
python3 setup.py config --compiler=intelem --fcompiler=intelem build_clib --compiler=intelem --fcompiler=intelem build_ext --compiler=intelem --fcompiler=intelem
[repeat these two another 4 times, to be sure, and it should be ready for packaging]

In other words: try compiling setting the __INTEL_PRE_CFLAGS, and as soon as it fails, launch compilation WITHOUT setting the environment variable. It will continue from where the first try failed, and so on, until it gets it done.

By the way: there is also a bug in the "package_python*-scipy-mkl()" functions in the PKGBUILD. Where it says:

python* setup.py config_fc --fcompiler=intel install --prefix=/usr --root=${pkgdir} --optimize=1

It should be "--fcompiler=intelem". It needs to be corrected, or else the packaging will fail.


You can find a fully working PKGBUILD here: https://pastebin.com/ncpPC1xY

bred commented on 2017-11-05 12:15

Added 1.0

Unfortunately the fix for the _Float128 error does not works with scipy.
So at the moment the solutions seems to compile with gcc (edit PKGBUILD) or downgrade the glibc.


gwaterst commented on 2017-10-09 20:52

For numpy adding

export __INTEL_PRE_CFLAGS="$__INTEL_PRE_CFLAGS -D_Float128=__float128"

to the PKGBUILD solved the _Float128 error.
(compare https://aur.archlinux.org/packages/python-numpy-mkl/)

Here the build process quits at a later stage with the same error, so I wonder if the FLAG is overridden somewhere?

All comments