Package Details: python-numpy-mkl-bin 2.1.3.anaconda0-1

Git Clone URL: https://aur.archlinux.org/python-numpy-mkl-bin.git (read-only, click to copy)
Package Base: python-numpy-mkl-bin
Description: Scientific tools for Python - with Intel MKL - prebuilt binaries from Anaconda
Upstream URL: https://numpy.org
Licenses: BSD-3-Clause
Conflicts: python-numpy
Provides: python-numpy
Submitter: chrisjbillington
Maintainer: carlosal1015
Last Packager: carlosal1015
Votes: 1
Popularity: 0.000000
First Submitted: 2019-11-18 03:28 (UTC)
Last Updated: 2024-11-20 02:43 (UTC)

Dependencies (2)

Required by (1912)

Sources (1)

Pinned Comments

Latest Comments

1 2 Next › Last »

4rozenwolves commented on 2022-02-04 05:33 (UTC)

Thank you, it seems to be working now.

chrisjbillington commented on 2022-02-04 04:46 (UTC)

@4rozenwolves, I see that the problem was anaconda's numpy not being compatible with the latest intel-mkl and intel-openmp. I've downgraded the versions of intel-mkl and intel-openmp in the pinned comment to be those required by anaconda's numpy build.

chrisjbillington commented on 2022-02-04 04:44 (UTC)

Note: these python-*-mkl-bin packages require version 2021.4.0 of intel-mkl and openmp, which are out of date in the Arch repos for licensing reasons (the newer versions can't be redistributed without permission).

It is against the AUR submission rules to add a package to the AUR solely because the package in the repositories is out of date, so here are two PKGBUILDs in the form of pastebin pastes for the latest intel-mkl and intel-openmp, (both prebuilt binaries from anaconda), you can use these until the packages in the repos are updated:

intel-mkl-bin 2021.4.0 PKGBUILD

intel-openmp-bin 2021.4.0 PKGBUILD

chrisjbillington commented on 2022-02-04 04:27 (UTC)

Thanks @4rozenwolves, I see now that the problem was me not clean-building. I see the same issue when I do clean-build intel-mkl-bin. I'll investigate.

4rozenwolves commented on 2022-02-04 04:19 (UTC)

I installed the pinned intel-mkl-bin from your pinned comment.

I noticed that neither libmkl_rt.so.1 nor any *.so.1 are inside mkl-2022.0.1-h06a4308_117.tar.bz2

chrisjbillington commented on 2022-02-04 03:57 (UTC) (edited on 2022-02-04 03:58 (UTC) by chrisjbillington)

Hi @4rozenwolves, I have that .so on my system and it is owned by intel-mkl-bin:

$ pacman -Qo /usr/lib/libmkl_rt*
/usr/lib/libmkl_rt.so is owned by intel-mkl-bin 2022.0.1.anaconda117-1
/usr/lib/libmkl_rt.so.1 is owned by intel-mkl-bin 2022.0.1.anaconda117-1
/usr/lib/libmkl_rt.so.2 is owned by intel-mkl-bin 2022.0.1.anaconda117-1

The required intel-mkl-bin is available only as the PKGBUILD I've linked in the pinned comment. Ensure you've got the latest version and have clean-built - it sounds like perhaps you've ended up with an older one somehow (for example if you cloned the intel-mkl-bin AUR repo - that's on old AUR package that was deleted once intel-mkl was included in [community])

4rozenwolves commented on 2022-02-04 03:49 (UTC)

I encountered libmkl_rt.so.1: cannot open shared object file: No such file or directory when running import numpy. I installed intel-mkl-bin, intel-openmp-bin, and python-mkl-service-bin. I only found /usr/lib/libmkl_rt.so and /usr/lib/libmkl_rt.so.2 in the intel-mkl-bin.

chrisjbillington commented on 2022-01-19 07:52 (UTC)

@hel thanks for the report. This used to be /opt/anaconda1anaconda2anaconda3 and the PKGBUILD was doing prefix replacement to replace it with /usr/ - but the placeholder has apparently changed. I shouldn't rely on it always being the same and am now looking it up in the anaconda package metadata correctly. The problem should be fixed, let me know if there are still any issues.

hel commented on 2022-01-19 04:42 (UTC) (edited on 2022-01-19 04:57 (UTC) by hel)

f2py contains

'''exec' /tmp/build/80754af9/numpy_and_numpy_base_1639496814640/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/bin/python "$0" "$@"

instead of the actual path to python. I see the same in numpy.__config__.show() for library_dirs