Hi Developers
I have built SciPy wheel with openblas from OpenMathLib(OpenMathLib · GitHub) using pkg-config method on windows without scipy-openblas32. How to link the built openblas.dll dynamically with wheel to get the functionality of BLAS/LAPACK packages?
Thanks
The short answer is that Windows doesn’t have RPATH support, so for any DLLs that aren’t in a directory that’s searched for DLLs by default, you should use os.add_dll_directory to add that directory to the search path. You can edit scipy/_distributor_init.py to do so.
Alternatively, you can run delvewheel over the built SciPy wheel. That will vendor the openblas and libgfortran DLLs into the wheel. The README of GitHub - adang1345/delvewheel: Self-contained Python wheels for Windows will have more details.
Thanks
You don’t build wheels from a build or build-install dir. Rather, starting from a clean repository, you build a wheel with python -m build --wheel for local usage.
In case you want a redistributable wheel, that is a bit harder - see Building redistributable binaries — SciPy v1.15.0.dev Manual for docs.
For (2), yes any OpenBLAS or other BLAS/LAPACK library, see BLAS and LAPACK — SciPy v1.15.0.dev Manual.
@rgommers
I tried the following command you shared, but it tries to download numpy source code and building numpy on top of it, is there any reason why numpy comes into play here? Since i am having my own numpy installed via pypi
That is what is called “build isolation” - it’s build doing that (pip will do the same). Use python -m build -wnx to disable build isolation.
@rgommers Thanks, will try it out come back
Thanks @rgommers man! this works fine, now I have got the wheel how can I run tests on this wheel?
Install it, the pytest --pyargs scipy or in the interpreter import scipy; scipy.test().
Note that all of this is completely standard usage of build and pytest, the defaults as in the docs of those projects just work.
Hi @rgommers
I could see the prebuilt x64 scipy wheel includes scipy.libs that contains openblas.dll get loaded at runtime. Presently my wheel which I built using pkg config does contain this scipy.libs and therefore I am adding its path directly on distributor_init file. How does python -m build -wnx can be used/modified in such way that the wheel includes my local openblas.dll in it and that be loaded automatically?
My scipy wheel :
Prebuilt Scipy wheel:
The short answer is: use delvewheel.
For more details, I recommend looking at the CI jobs that build the SciPy wheels. Latest log is at Wheel builder · scipy/scipy@81385df · GitHub
Hi All,
I’m building SciPy on an x64 machine using MSVC and Intel Fortran compiler for debugging purposes. While I was able to generate the wheels, I’m encountering a ‘DLL load failed while importing _arpack’ error at runtime. I followed the instructions for building OpenBLAS (How to use OpenBLAS in Microsoft Visual Studio · OpenMathLib/OpenBLAS Wiki · GitHub) and added the DLL directory path to the environment variables and distributor_init file. Can anyone point out what might be missing or causing this issue?
Thanks in advance!
On Windows that compiler configuration builds, but doesn’t run. We have a CI job to stop the bleeding with Intel compilers, and on Windows it has the same issue as you ran into: scipy/.github/workflows/windows_intel_oneAPI.yml at main · scipy/scipy · GitHub. So you’re not missing anything easy I’m afraid.
Intel compilers are unfortunately very hard to support, both their packaging and stability are really poor. At Building from source — SciPy v1.15.0.dev Manual we have the known-working compilers listed; we only have the legacy icc/ifort and not icx/ifx. We should be adding the new LLVM-based Flang 19 there, that works as well and is used in Conda-forge’s SciPy packages. I’d go with something that’s known to work here.
