We Keep Coding

'win32ctypes.pywin32.pywintypes.error: (87, 'UpdateResource', 'The parameter is incorrect')' error when assigning icon with pyinstaller

I am using pyinstaller to create an executable from a .py file type and attaching an icon to it using the command
pyinstaller.exe --onefile --windowed --icon="test.ico" test.py
The '.ico' is 500px by 500px and 24bit depth and was created with Photoshop and exported as a '.bmp' and then manually changed to a '.ico' and worked fine when assigned to a folder but when trying to assign it to the pyinstaller executable I keep getting the error:
raise error(exception.winerror, exception.function, exception.strerror)
win32ctypes.pywin32.pywintypes.error: (87, 'UpdateResource', 'The parameter is incorrect')
How to fix this?

After further investigation it appears that the icon file was not generated correctly.
If anyone is having this issue use: icoconverter.com to convert your image properly

WinError 6 - The handle is invalid with executable but code works on debug mode

I'm using a software that handle video processing in a powershell subprocess.
With PyCharm, when I run my software (in debug mode) everything works as expected.
When I use pyinstaller and inno setup to make an executable and install it on windows I got this error when Sub process start :
[WinError 6] The handle is invalid
I suppose it’s due to an error in a subprocess like this piece of code :
try:
psa1_path = EnvValues.powershell_path().format(project=project)
# using this powershell : C:/Users/${USERNAME}\projects\demo\cmd\powershell.ps1 -m -v 'CC 2018' -wait windowstyle hidden
dc_logger.info(f'using this powershell : {psa1_path}')
if project:
dc_logger.info("PowerShell Rendering Started")
with open(EnvValues.frame_path(), 'a') as f:
p = subprocess.Popen(['C:\\WINDOWS\\system32\\WindowsPowerShell\\v1.0\\powershell.exe',
'-ExecutionPolicy',
'Unrestricted',
psa1_path],
stdout=f)
p.communicate()
dc_logger.info("PowerShell Done Rendering")
return True
else:
dc_logger.info("no project to render")
return False
Is the bug related to arguments passed to the subprocess ? Why executable version of the code is the only one not working ? Why I don't have the bug in the development version ?
Here's my pyinstaller cmds :
pyinstaller --onefile -w -F -i "C:\Users\my_project\icon.ico" Project.py
pyinstaller --onefile -w -F -i "C:\Users\my_project\icon.ico" Project.spec
Then I put this in InnoSetup and I install the output to my windows machine.

The problem is with psa1_path variable
C:/Users/${USERNAME}\projects\demo\cmd\powershell.ps1 -m -v 'CC 2018' -wait windowstyle hidden
This variable has parameters. And the subprocess.Popen use it as a string, then you have to set shell=True so Popen will use this string as a complete shell cmd.
p = subprocess.Popen(['C:\\WINDOWS\\system32\\WindowsPowerShell\\v1.0\\powershell.exe',
'-ExecutionPolicy',
'Unrestricted',
psa1_path],
stdout=f, shell=True, stdin=subprocess.DEVNULL)
Don't forget to add stdin arg because it's also throw the [WinError 6] The handle is invalid
So why the code works with debug code and not with executable :
It's mainly because PyCharm does additionnal configuration and setup behind the scenes when it comes to running a program.
Because when you’re going from IDE to runtime, you need additional hooks to get things going. pyinstaller doesn’t do the subprocess the same way as pyCharm for the shell part

ModuleNotFoundError: py3k for PyInstaller + savReaderWriter

I want to use PyInstaller with module savReaderWriter. My code is very simple:
import savReaderWriter
print("hello world")
input("Press enter, to finish...")
I was trying to use hidden import with appropriate module:
pyinstaller --clean --win-private-assemblies --upx-exclude=vcruntime140.dll --onedir --hidden-import="savReaderWriter" temp.py
pyinstaller --clean --win-private-assemblies --upx-exclude=vcruntime140.dll --onedir --hidden-import="py3k" temp.py
pyinstaller --clean --win-private-assemblies --upx-exclude=vcruntime140.dll --onedir --hidden-import="py3k" --hidden-import="savReaderWriter" temp.py
But in all cases I have received the same error:
ModuleNotFoundError: No module named 'py3k'

I solved the issue by including the path of the savReaderWriter to the parameter.
pyinstaller -p "C:\PyProjects\test\venv\Lib\site-packages\savReaderWriter"; test.py
Also, the real pain is when you trying to delete the module, an Error will occur because it is finding a non "UTF-8" character.

pywintypes.error - Using pyinstaller to create a one-file bundled executable

Running Powershell in the same directory as:
pyinstaller --onefile --icon=<my_Logo.ico> BC-USD.py
It always end up with the same error:
pywintypes.error: (2, 'LoadLibraryEx', 'The system cannot find the file specified.')
How can I fix this?

Does your code import a dll? If so, you need to tell pyinstaller to include it using the --add-binary or --add-data option:
pyinstaller --onefile --icon="icon.ico" --add-binary "current/path/to/dll/my_dll.dll; folder/to/store/dll/inside/pyinstaller/bundle"
http://pyinstaller.readthedocs.io/en/stable/usage.html

How to set compiler in waf

I'm trying to compile 3rd party software which uses waf as the build tool. I run into problems immediately.
> python waf configure --prefix=install
Checking for program 'g++, c++' : CC
Could not determine the compiler version ['CC', '-dM', '-E', '-']
The config.log file says (with some extra crap deleted):
Checking for program 'g++, c++'
CC
['CC', '-dM', '-E', '-']
out: No supported cpu target is set, CRAY_CPU_TARGET=x86-64 will be used.
Load a valid targeting module or set CRAY_CPU_TARGET
err: CC-2130 crayc++: WARNING in command line
The "-d" commandline option is unsupported.
CC-2289 crayc++: ERROR in command line
Invalid characters after option '-d' in command line item '-dM'.
CC-2107 crayc++: ERROR in command line
No valid filenames are specified on the command line.
I don't know how to debug waf scripts. Does anyone have any suggestions? I guess that I have to tell waf to use gcc (or c++) as the compiler, but I can't even figure out how to tell waf to do that. waf has an argument --check-cxx-compiler, but that doesn't appear to work.