The page here http://www.chromium.org/developers/testing/pyauto#TOC-Running-PyAuto-using-prebuilt-binaries suggests using the files here http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?path=Win/140227/ to install it yourself, but I'm not exactly sure what I have to do.
I ran mini_installer successfully, put pyauto and _pyauto in the site_packages, and the dll in system32 folder.
This is the error I get when I try to run the automated_ui_test.exe http://pastebin.com/Ab0vCCWk
I am also unable to figure out where this is supposed to be chrome/test/pyautolib/fetch_prebuilt_pyauto.py EDIT: found it here http://src.chromium.org/svn/trunk/src/chrome/test/pyautolib/
EDIT2: Got it 'built' or something, now I have a set of files in the path I set. Now when I try to import pyautolib, I get the following error: ImportError: DLL load failed: %1 is not a valid Win32 application. I think this has something to do with me being on 64bit. Generally when this happens, I check out http://www.lfd.uci.edu/~gohlke/pythonlibs/ which has quite a few 64bit python packages, but it's not there this time.
What need to do to run PyAuto on a Windows 7, 64bit machine?
There is no support for pyAuto on 64-bit Chrome currently http://www.chromium.org/developers/design-documents/64-bit-support
A 64-bit version of Chromium can be built on Linux by using the -Dtarget_arch=x64 flag on the GYP build system. (This is the default on 64-bit Linux systems.)
The 64-bit version of the V8 JavaScript engine used by Chromium can be built separately using the --arch=x64 flag in v8's Scons build system. This works on both the Linux and Mac OS X platforms.
Neither Chromium nor V8 has a 64-bit version on the Windows platform right now. However, Chrome does run on 64-bit Windows as a 32-bit application. V8 should only need a small number of changes to build on the Windows platform.
Related
I build exe file using pyinstaller in windows 10 64bit os. but when i test on windows7 64bit os then is not working. that shows dll file error.
so, I understated when the os is change then need to rebuilt exe file with that same system. am I Right ?
pyinstaller --onefile -w --icon=pp-logo.ico WCS_Config_App.py --hiddenimport=pyserial --hiddenimport=numpy
this above way i create exe file.
So, I want to build exe file(standalone) execute for all windows system.
Thank you for your time.
You can surelly build an app for all windows versions but compiling can be really tricky especially with big apps.The main considerations to take is:
Python version.Not all versions of windows are capable of running all versions of python so for example since you want an XP compatibility too you will need to build your app with python3 version <= 3.4.3.
x32 or x64 must be taken as consideration , as if you build an app with x64 python will only run with x64 operating systems.
DLL for windows is required(probably this is your current problem) and you will need to include the VC REDISTs required for each type of os(windows XP,7,10).You can accomplish this prety easy with an installer like inno-setup.
I am running python 3.9.1 for windows 10 (x64). I have noticed the openssl dll files shipped with python (libcrypto-1_1.dll & libssl-1_1.dll) are only version 1.1.1.7. I would therefore like to replace these with the latest versions.
I have been able to successfully build openssl 1.1.1.9 in windows 10 following the instructions in the release. I am using Microsoft visual studio 2019 + strawberry perl + nasm. I ran the following config command using the x64 native tools command prompt for vs 2019:
perl Configure VC-WIN64A
I then run the nmake command. This produces the two dlls I need: libcrypto-1_1-x64.dll and libssl-1_1-x64.dll
I renamed both files to remove the "-x64" at the end of the name and then used them to replace the existing dlls in the python installation.
When I try to import the ssl library in python, I get the error:
ImportError: DLL load failed while importing _ssl: The specified module could not be found.
I then built openssl for x86, using the x86 native tools command prompt for vs 2019 and the command:
perl Configure VC-WIN32
I then ran nmake which produced: libcrypto-1_1.dll and libssl-1_1.dll
I replaced the dlls in the python installation with those. When I try and import the ssl library in python I get:
ImportError: DLL load failed while importing _ssl: %1 is not a valid Win32 application.
I am reasonably certain I need the x64 version of the dlls because (1) my python installation is x64 (2) when I used the visual studio dumpbin.exe tool on the python shipped dlls to inspect the headers they say "x64" in them (3) the x64 dlls are a similar size to the ones shipped with python and the x86 versions are smaller.
I was once able to do this following the above steps for an older version of python. That version shipped with openssl 1.1.3 (could be 4) and I built the dlls for 1.1.6 (could be 7) and replaced them and python had no issues. Is it possible that the default configuration scripts have changed over these versions such that the default windows x64 configuration no longer builds openssl in a way that works with python and I therefore need to use custom settings?
I think the info at section 1.3 of this page may be relevant, but if it is I am not sure how to implement that in the openssl build process.
I managed to solve this with some help.
The scripts used by CPython to build OpenSSL for the windows installers actually run the command:
Perl Configure VC-WIN64A-masm no-asm
instead of
Perl Configure VC-WIN64A
After running the correct command on the setup described in my original post I was able to swap out the dlls and python accepted them without issue.
ssl.OPENSSL_VERSION now outputs ‘OpenSSL 1.1.1i 8 Dec 2020’.
I am creating an installer for the application I have developed. Below is the setup file I am using
from cx_Freeze import setup, Executable
buildOptions = dict(excludes = ["tkinter"], includes =["idna.idnadata"], optimize=1)
setup(name = "SoftwareGateway" ,
version = "0.1" ,
description = "" ,
options =dict(build_exe = buildOptions),
executables = [Executable("main.py", base = base)])
By default this builds an installer for a 32-bit target. I am saying this because, when I install this, it gets installed in ProgramFiles(x86).
The problem I am facing is, I have an IoT-Hub client library which is 64-bit (.pyc file). I am able to create the installer but that is for x86. When I install and try to run, it throws an error
DLL load failed, %1 is not valid win32 application
So, as a first step, I would like to create an installer for a 64-bit target and see if it works. Please provide a way with which I can create an installer for a 64-bit machine.
Later I will try to find an IoT-Hub client library for 32-bit and build it for x86 as well.
cx_Freeze basically creates an executable for the platform and configuration of the python installation it belongs to. Quoting the cx_Freeze documentation:
cx_Freeze works on Windows, Mac and Linux, but on each platform it only makes an executable that runs on that platform. So if you want to freeze your program for Windows, freeze it on Windows; if you want to run it on Macs, freeze it on a Mac.
So on a Windows 64-bit machine, you can create a 64-bit executable by running the setup script using a 64-bit python installation. This executable will work on Windows 64-bit machines only.
On a Windows 64-bit machine, you can also create a 32-bit executable by running the setup script using a 32-bit python installation. This executable will work on Windows 32-bit and 64-bit machines. See also Can I make a 32 bit program with cx_freeze if I have a 64 bit OS?
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.
Pyinstaller produces a binary depending from the python you used to build it. So if you use python 2.7 64 bit it is not possible, as far as I know, to produce a 32 bit executable. This is because Pyinstaller archives all modules and their dependencies (dlls, pyds etc..) which are 64 bit due to the python install.
As already said it is better, because of cross compatibility issues, to build 32-bit binaries.
Probably you can specify more your question.
If you are building an application and it runs fine on 32-bit Windows, there is no need to create a 64-bit version. Just create a 32-bit version and run it on both architectures. What is what WOW64 is for.
If you need to use a library or feature which is 64-bit only, just build a 64-bit version. There is no point in building a 32-bit version if the feature is 64-bit only.
The only reason to build a 64-bit and 32-bit version both, is to take advantage of increased address space of 64-bit windows. I.e. if you intend to allocate more than 1 or 2 GB of memory. An example might be an image editing application, or a data manipulation application. Then you can run on 32-bit platforms within the constraints of the platform but edit larger images or larger quantities of data on 64-bit platforms.
IOW, for your case follow the suggestion of #Velociraptors and build in 32-bit python if you are building a 32-bit exe.
If you want to build a 32-bit application on a 64-bit system and hav only a 64-bit version of Python installed, you have to install also a 32-bit version of Python. Then you have to instal pyinstaller to that 32-bit Python version as follows:
path/to/32-bit/python -m pip install pyinstaller
After that you can run the 32-bit version of pyinstaller, and thus build a 32-bit application, like this:
path/to/32-bit/pyinstaller your-app.py
On Windows 10, pyinstaller.exe is located at C:\Users\<user>\AppData\Local\Programs\Python\Python<version>-32\Scripts\pyinstaller.exe.
As you can see, the architecture of the application you want to build depends on the Python and pyinstaller versions which you are going to use to build that application. This way you can also, for instance, build an application from a Python version 2.x if you have it installed on the system.
I'm running Python 2.7 on Windows 7 64-bit, and when I run the installer for setuptools it tells me that Python 2.7 is not installed. The specific error message is:
`Python Version 2.7 required which was not found in the registry`
My installed version of Python is:
`Python 2.7 (r27:82525, Jul 4 2010, 07:43:08) [MSC v.1500 64 bit (AMD64)] on win32`
I'm looking at the setuptools site and it doesn't mention any installers for 64-bit Windows. Have I missed something or do I have to install this from source?
Problem: you have 64-bit Python, and a 32-bit installer. This will cause problems for extension modules.
The reasons why the installer doesn't finds Python is the transparent 32-bit emulation from Windows 7. 64-bit and 32-bit programs will write to different parts of the Windows registry.
64-bit: HKLM|HKCU\SOFTWARE\
32-bit: HKLM|HKCU\SOFTWARE\wow6432node\.
This means that the 64-bit Python installer writes to HKLM\SOFTWARE\Python, but the 32-bit setuptools installer looks at HKLM\SOFTWARE\wow6432node\Python (this is handled by windows automatically, programs don't notice). This is expected behavior and not a bug.
Usually, you have these choices:
the "clean" way: use 32-bit Python if you have to use 32-bit modules or extensions
the other "clean" way: only use 64-bit installers when using 64-bit Python (see below)
what the answer above suggests: copy HKLM\SOFTWARE\Python to HKLM\SOFTWARE\wow6432node\Python, but this will cause problems with binary distributions, as 64-bit Python can't load 32-bit compiled modules (do NOT do this!)
install pure Python modules with setuptools instead of the distutils installer (easy_install or pip)
For setuptools itself, for example, you can't use a 32-bit installer for 64-bit Python as it includes binary files. But there's a 64-bit installer at http://www.lfd.uci.edu/~gohlke/pythonlibs/ (has many installers for other modules too). Nowadays, many packages on PyPi have binary distributions, so you can install them via pip.
Apparently (having faced related 64- and 32-bit issues on OS X) there is a bug in the Windows installer. I stumbled across this workaround, which might help - basically, you create your own registry value HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.6\InstallPath and copy over the InstallPath value from HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.6\InstallPath. See the answer below for more details.
If you do this, beware that setuptools may only install 32-bit libraries.
NOTE: the responses below offer more detail, so please read them too.
I made a registry (.reg) file that will automatically change the registry for you. It works if it's installed in "C:\Python27":
Download 32-bit version HKEY_LOCAL_MACHINE|HKEY_CURRENT_USER\SOFTWARE\wow6432node\
Download 64-bit version HKEY_LOCAL_MACHINE|HKEY_CURRENT_USER\SOFTWARE\
Yes, you are correct, the issue is with 64-bit Python and 32-bit installer for setuptools.
The best way to get 64-bit setuptools installed on Windows is to download ez_setup.py to C:\Python27\Scripts and run it. It will download appropriate 64-bit .egg file for setuptools and install it for you.
Source: http://pypi.python.org/pypi/setuptools
P.S. I'd recommend against using 3rd party 64-bit .exe setuptools installers or manipulating registry
Create a file named python2.7.reg (registry file) and put this content into it:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Help]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Help\MainPythonDocumentation]
#="C:\\Python27\\Doc\\python26.chm"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath]
#="C:\\Python27\\"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath\InstallGroup]
#="Python 2.7"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Modules]
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\PythonPath]
#="C:\\Python27\\Lib;C:\\Python27\\DLLs;C:\\Python27\\Lib\\lib-tk"
And make sure every path is right!
Then run (merge) it and done :)
Get the file register.py from this gist. Save it on your C drive or D drive, go to CMD to run it with:
'python register.py'
Then you will be able to install it.
For 64-bit Python on Windows download ez_setup.py and run it; it will download the appropriate .egg file and install it for you.
At the time of writing the .exe installer does not support 64-bit versions of Python for Windows, due to a distutils installer compatibility issue.
To allow Windows installers to find the installed Python directory in Windows 7, OR, change which Python installation to install an installer into, add the installed path into the InstallPath registry key's (Default) value:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.X\InstallPath
Where "X" is the Python version (that is, 2.5, 2.6, or 2.7).
I tried the above and adding the registry keys to the LOCALMACHINE was not getting the job done. So in case you are still stuck , try this.
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Python]
[HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore]
[HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\2.7]
[HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\2.7\Help]
[HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\2.7\Help\Main Python Documentation]
#="C:\Python27\Doc\python272.chm"
[HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\2.7\InstallPath]
#="C:\Python27\"
[HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\2.7\InstallPath\InstallGroup]
#="Python 2.7"
[HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\2.7\Modules]
[HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\2.7\PythonPath]
#="C:\Python27\Lib;C:\Python27\DLLs;C:\Python27\Lib\lib-tk"
Copy paste the above in notepad and save it as Python27.reg . Now run/merge the file as mentioned in the answers above. (Make sure the paths of Python installation are corrected as per your installation.
It simply does ,what the above answers suggest for a local machine ,to the current user.
Here is a link to another post/thread. I was able run this script to automate registration of Python 2.7. (Make sure to run it from the Python 2.x .exe you want to register!)
To register Python 3.x I had to modify the print syntax and import winreg (instead of _winreg), then run the Python 3 .exe.
https://stackoverflow.com/a/29633714/3568893
You can find 64bit installers for a lot of libs here: http://www.lfd.uci.edu/~gohlke/pythonlibs/