Compiled EXE crashes (exception) - it previously (apparently updated some modules) worked fine.

[KobiHaMitapes]

I compiled a python gui application using pyinstaller. Here is the compilation statement:
pyinstaller RoundTripDialog.py --add-data "icon/chromatic_small.ico;." --icon "icon/chromatic_small.ico" --splash splash.png -F --hidden-import lcms --hidden-import scipy --hidden-import scipy.interpolate --hidden-import scipy.spatial.cKDTree --hidden-import sklearn.metrics._pairwise_distances_reduction._datasets_pair --hidden-import sklearn.metrics._pairwise_distances_reduction._middle_term_computer --hidden-import scipy._lib._uarray._backend --name RoundTripTool --onefile

I get errors upon runing the executable - see the screenshot

Somehow _uarray is being found. In a previous compilation before I updated pyinstaller and modules, I was able to successfully run the executable. Has anyone experienced this before? Can anyone shed light on what i can to do correct this?
Thanks.

[rokm]

That looks like a missing or incompatible dependency of scipy._lib._uarray._uarray binary extension. Although the only dependencies I can see are the python shared library and api-ms-* DLLs, which should not be a problem on contemporary Win 10/11 systems.

Does it help if you rebuild with added --clean option?

What version of python, PyInstaller, and scipy are you using? Is this python.org + pip, or anaconda python environment?

Does the issue also occur if you freeze a simple

import scipy._lib._uarray
print("hello")

program in onedir mode instead of onefile one?

If it does, can you archive build and dist directories (for this test program only) and upload the archive somewhere so I can take a look at it?

[rokm]

Actually, one thing came to mind - since this is PyPI scipy and Anaconda python 3.8, it could be that the issue is due to delvewheel load order file not being collected from scipy.libs directory - we nominally added support for that in v5.6 (fe4a77c), but I think the particular load order filename format used by scipy-1.10.1 PyPI wheel will be picked up only after v5.11.0 (75f86ee).

EDIT: on the second thought, that might not be the problem; the filename format seems to be using dash and not underscore, so it should be handled by 5.6 variant...

[KobiHaMitapes]

So I upgraded pyinstaller to 5.13.2 using pip. It was a bit interesting because I could not uninstall using conda so I have to take care of some issues with pathlib - but I overcame that. I ended up with the same issue. So, I made a simple project with, as you said:

import scipy._lib._uarray
print("hello")

Worked fine, in python.
I compiled it using:
pyinstaller --clean uarrayTest.py --onedir --name uarrayTestCase
Went into the directory created and ran the exe in command line and got:

Please find a link, below, to icloud to download the zip file. If all goes well, you'll find the executable and the rest of the package there. Perhaps you'll see my (probably very silly) mistake and can let me know what I need to do to fix this. The zip file is about 241mb - not sure what the download speed will be. If this method doesn't work, let me know and I'll find another way to get the zip file to you.

https://www.icloud.com/iclouddrive/047_lLL_3psUMZPEoPbH5Lp7Q#uarrayTestCase

[bwoodsend]

It was a bit interesting because I could not uninstall using conda so I have to take care of some issues with pathlib

Please use a clean environment. The sloppy broken residues of a butchered conda environment are exactly want we want to eliminate as a potential cause of all this.

[rokm]

Hmm, some of those libs are suspiciously small - are you perhaps using UPX during the build?

[KobiHaMitapes]

I’ll answer you both. The butchered conda seems not to be the issue only because it was the same before I upgraded the pyinstaller.
yes there is upx and I am not sure I understand why. I don’t ask for it in my compile statement which I wrote above. Also in my real app the one file exe is larger than before when things worked with out the DLL not being found.
how can I do it again and specify no upx?

[rokm]

Either remove UPX from PATH, or add --noupx to your PyInstaller command.

[KobiHaMitapes]

Continuing the thread ... I removed the upx from the small test case and indeed it does now work.
Is it possible that the upx is the culprit? If so - yes you're right. I apparently so quickly put the upx into the path or as a variable (need to go through and see how i got it in there) and for the thing I was compiling then, it had no real effect. However, for this particular module, with the kd-tree, this behavior started.
I will try to compile the larger project and see whether it comes up now. If it does, I'll mark it as the solution - albeit I am not sure this is what was intended with UPX ! But that is actually not that important to me. We can talk about the size and startup time at a different time. The most important thing is that if changes need to be made, that we can compile.

[bwoodsend]

I think we should consider making upx opt-in rather than opt out if UPX happens to be available.