Short Question
Is there any way to control / guarantee the architecture (32bit vs 64bit) when building a pyinstaller executable?
Background
I migrated from py2exe to pyinstaller because of the lack of 64bit support along with a host of small things that I am having a hard time looking past. So on that note, I would prefer not to go back to it. I have developed two applications using Python 2.7 64bit and am having performance issues when running on them 32 bit machines.
The first is a simple wxPython GUI (version 2.9) and connects to a windows DLL file for a USB driver. This one seems pretty "safe" to run as 32 bit because there are no modules which are 64bit only. However this application when running on 32bit Windows XP has horrible performance issues when talking to the USB device.
The second application is much larger and I have not attempted to build and run yet because of the fear of architecture issues. This application has a number 64bit only modules (psycopg2 for one) used in it. I would like to stay away from trying to build this if it impossible to run as a 32bit executable.
Current Thoughts
I feel that this might be possible (if the modules have 32bit support) by running the build.py with Python forced in 32bit mode. Does this make any sense?
Update
I had several breakthroughs on the first program I was building. It turns out the performance issues was solely based on the speed of the two machines. My dev machine had enough power to poll the USB device fast enough and the much slower test platform (Windows XP) did not.
I fixed this issue by modifying the way I polled the USB port. Now that this was fixed, I could run the exe on both systems. A new problem had come up when trying to build the executable as a single file. When running pyinstaller's Build.py, it pulls in all of the required DLL's the app needs to run. This seemed to work great at first, but when I tried to run the single exe that I built on Windows 7 64bit, it would not run on Windows XP because the USB dongle's DLL was not recognized as a valid DLL.
In order to get the single exe to run on both systems, I first tried to remove the DLL from the .spec file (which appears to be a python script). It was convenient because I was able to modify the list of includes prior to the build command with ordinary python list modifiers. My hope was that if the DLL was not found in the exe's temp directory it would find it on the system PATH. While this approach might work, I could not get it to run without throwing lots of errors.
My second attempt was to build the application on the Windows XP machine (leaving the DLL embedded) in hope that the Win XP DLL would work in Windows 7. Success! This configuration works well; however I do strongly believe that this not the best solution as it depends solely on the older DLL running on a newer OS.
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…