ImportErrir: DLL load failed for Windows

[pmayd]

Hello,

we experience a critical ImportError with the latest numexpr version under Windows. The error is an ImportError and the tracestack is :

c:\users\gsj5sl8\miniconda3\lib\site-packages\numpy\_distributor_init.py:30: UserWarning: loaded more than 1 DLL from .libs:
c:\users\gsj5sl8\miniconda3\lib\site-packages\numpy\.libs\libopenblas.NOIJJG62EMASZI6NYURL6JBKM4EVBGM7.gfortran-win_amd64.dll
c:\users\gsj5sl8\miniconda3\lib\site-packages\numpy\.libs\libopenblas.WCDJNK7YVMPZQ2ME2ZZHJJRJ3JIKNDB7.gfortran-win_amd64.dll
  warnings.warn("loaded more than 1 DLL from .libs:"
Traceback (most recent call last):
  File "c:\users\gsj5sl8\miniconda3\lib\runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "c:\users\gsj5sl8\miniconda3\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\gsj5sl8\Miniconda3\Scripts\mdf2parquet.exe\__main__.py", line 4, in <module>
  File "c:\users\gsj5sl8\miniconda3\lib\site-packages\mdf_converter\app.py", line 10, in <module>
    from .mdf_converter.analyzer import Analyzer
  File "c:\users\gsj5sl8\miniconda3\lib\site-packages\mdf_converter\mdf_converter\analyzer.py", line 10, in <module>
    from . import io
  File "c:\users\gsj5sl8\miniconda3\lib\site-packages\mdf_converter\mdf_converter\io.py", line 17, in <module>
    from asammdf import MDF
  File "c:\users\gsj5sl8\miniconda3\lib\site-packages\asammdf\__init__.py", line 14, in <module>
    from .blocks.mdf_v2 import MDF2
  File "c:\users\gsj5sl8\miniconda3\lib\site-packages\asammdf\blocks\mdf_v2.py", line 4, in <module>
    from .mdf_v3 import MDF3
  File "c:\users\gsj5sl8\miniconda3\lib\site-packages\asammdf\blocks\mdf_v3.py", line 37, in <module>
    from ..signal import Signal
  File "c:\users\gsj5sl8\miniconda3\lib\site-packages\asammdf\signal.py", line 10, in <module>
    from .blocks import v2_v3_blocks as v3b
  File "c:\users\gsj5sl8\miniconda3\lib\site-packages\asammdf\blocks\v2_v3_blocks.py", line 12, in <module>
    from numexpr import evaluate
  File "c:\users\gsj5sl8\miniconda3\lib\site-packages\numexpr\__init__.py", line 26, in <module>
   from numexpr.interpreter import MAX_THREADS, use_vml, __BLOCK_SIZE1__
ImportError: DLL load failed while importing interpreter: Das angegebene Modul wurde nicht gefunden.

This error occurs for both native Python and Miniconda distribution. When we switch back to numexpr 2.7.0. everything works. I am not sure why this error occurs and it does not occur on all windows systems, but we have this problem now with Windows 10 Enterprise, Build 10.0.18363

[robbmcleod]

What exactly is the 'lastest' version? Please provide a version number. What version of numpy are you using? Where did you download the wheel from? I.e. did you install via pip or conda?

[pmayd]

Version is latest, so 2.7.2.

Same for numpy, latest version as of today for python 3.8.5., the error is from today. I have used pip install command so wheel is from pypi. I tried both a pure python setup and with miniconda, but I installed the package with pip not conda.

[danielhrisca]

I also have this problem: I've created a standalone application using PyInstaller. On some PCs this import error pops up, but on the majority it is working correctly.

[robbmcleod]

Really not enough information to solve the problem.

What is the difference between the PC configurations on which it works versus doesn't?

[danielhrisca]

Multiple PCs with this configuration had the problem using numexpr 2.7.2 but no problem with numexpr 2.6.9 (possibly even 2.7.1)

On my laptop I had no problem running either of the numexpr versions

[danielhrisca]

We've been able to narrow down the problem: 2.7.1 works and 2.7.2 does not work

[robbmcleod]

Really need more information in order to possibly replicate the problem. It sounds like some sort of binary interface issue.

• What version of NumPy is installed/pinned to?
• What version of the MSVC runtime is installed?
• Can machines with MSVC build tools installed built the package without issues from the source dist?

The issue is likely somehow related to the use of cibuildwheels to make the wheels, but without knowing the differences between the GitHub Actions build machines, and these problem machines, I cannot help. So please be more proactive.

[danielhrisca]

We build the standalone executable using PyInstaller on a dedicated PC that has numpy 1.20.1 (from PyPI, not from some MKL custom build) MSCV installed:

The executable is the distributed and used on different machines. On the problematic machines we have seen this behavior:

• standalone executable that bundles numexpr 2.6.9 from PyPI: works on all machines
• standalone executable that bundles numexpr 2.7.1 from PyPI: works on all machines
• standalone executable that bundles numexpr 2.7.2 from PyPI: does not work
• standalone executable that bundles numexpr 2.7.2 build from source: does not work

[robbmcleod]

When you say, "does not work," do you mean does not work on the build machine, or does not work on the target machine? Does the target machine have the same runtimes for MSVC that you are building with?

Does it work without being bundled by PyInstaller?

Can you attached a debugger to the process to see what's causing the DLL ImportError? Or maybe use Dependency Walker (if that still works in this day-and-age).

I still don't know what version of Python you are running. With Python one is supposed to use the same version of MSVC to build c-extensions as were used to build Python.

[danielhrisca]

Does it work without being bundled by PyInstaller?

On my PC it runs both ways. I cannot run from source on the problematic PCs because I don't have access there.

Can you attached a debugger to the process to see what's causing the DLL ImportError? Or maybe use Dependency Walker (if that still works in this day-and-age).

I've never done this, but more importantly I don't have access

I still don't know what version of Python you are running. With Python one is supposed to use the same version of MSVC to build c-extensions as were used to build Python.

The build is done with Python 3.7.9 x64

When you say, "does not work," do you mean does not work on the build machine, or does not work on the target machine? Does the target machine have the same runtimes for MSVC that you are building with?

I'll have to check this

[danielhrisca]

It seems

When you say, "does not work," do you mean does not work on the build machine, or does not work on the target machine? Does the target machine have the same runtimes for MSVC that you are building with?

I've asked my colleagues to install the latest MSVC runtime and the problem was solved

[robbmcleod]

One potential fix would be to make use of https://github.com/scipy/oldest-supported-numpy and try and new release to make sure that the wheels are built with the oldest API. I'll look into building a new release.

[robbmcleod]

I did a new release, version 2.7.3, please let me know if the new wheels perform better on machines with older copies of the MSVC runtime installed.

[danielhrisca]

I did a new release, version 2.7.3, please let me know if the new wheels perform better on machines with older copies of the MSVC runtime installed.

I'm afraid the new release still does not work with the older runtime

[andreasWallner]

I have the same issue here when trying to import numexpr. I'm using:

• python 3.9.8 64bit (from https://winpython.github.io/) they hint at the need to install 2017...2019 redistributable
• pip to install from pypi
• numexpr 2.7.3
• numpy 1.21.4+mkl
• installed MSVC redistributables (in both 32 and 64bit): 2005, 2008, 2010, 2013, 2015...2022

Any idea what might help here?

[robbmcleod]

This sort of thing is really beyond my ability to troubleshoot for people. As people above have suggested, perhaps try uninstalling the MSVC runtime and install the latest version?

[github-actions[bot]]

Message to comment on stale issues. If none provided, will not mark issues stale