What I'm trying to do is install SIP 4.14.7 through Cygwin using the make command. I'm running Python version 3.3.2 (with Python added to the PATH) on a Windows 7 x64 SP1 machine with 4GB RAM and an Intel Core 2 Duo. Since what I'm doing is from within the Cygwin terminal, I'll avoid using the Win32 path format.
Following the installation instructions provided with sip-4.14.7.zip, here is what I've done:
Uncompressed the .zip into /c/python33/SIP/
Launched the Cygwin terminal and went to the /cygdrive/c/python33/SIP/ folder
Ran python configure.py (No options since I was fine with the default settings)
Ran make install
As far as I can tell, I followed the instructions as I should have, but obviously I'm not doing something right here.
Here's what happens:SCREENSHOT
The number of make.exe processes go up to about 1800 before Windows gets too low on memory and the whole thing reverses itself until there are no more 'make.exe' processes running as shown here: SCREENSHOT2
I've Googled this and searched around here on stackoverflow.com but couldn't find anything related to this particular issue. It seems that unless using the -j option the MAKE command should only process one job at a time. I've also tried using the -l option thinking it would limit the processes unless enough memory was available, but the results were the same.
I tried to provide as much detail as possible, but if there is any more information that I should post to help diagnose this issue, I'd be glad to provide it. Otherwise, any suggestions here would be much appreciated.
The latest version of Cygwin includes the PyQT4 package (in All->Python within Setup.exe). It's python-pyqt4 and python3-pyqt4. If you are trying to live in Cygwin, I'd install that version into Cygwin and use it. No make required from the looks of it.
Related
Dear community members,
I would like to have your opinions about my situation. I wrote some python modules to simplify the daily routine at work. I'm the only 'developer' and the user community is a handful of people with limited computer skills. The scripts should be available on several computers (Windows 7, 10 and 11) connected on a segregated network with no internet access.
I'm writing the code on a single PC (Windows 10) using Anaconda as environment and Spyder as IDE. The scripts are saved on a shared network disk that is accessible from all other PC in the segregated LAN.
And here comes my question: how should I package and distribute the code on all client PC?
My first idea was to not distribute it at all. I mean, I wanted to leave the code on the shared disk, and let the users double click on a shortcut on the desktop to have it running. The advantage is that I don't have to care about package creation and distribution.
Nevertheless I can see these limitations:
I need to install Anaconda on all PCs and, in particular on windows 7, I can only install an old release of it.
I need to modify the code in order that user-based configurations are saved on a local file and not on the shared disc.
In order to have access to shared modules between scripts, I need to add all relevant paths to the python search path on all PCs.
My second approach was to build an exe file for each script with pyinstaller and have them distributed on all clients. I can automatize the build and the copy on all pcs, so that I'm sure that everybody is using the same latest version. The advantage is that I don't need to install Anaconda everywhere but it has some drawbacks:
Each exe file is huge. All scripts have a Qt GUI and the size of the one-file exe generated by pyinstaller can easily reach 500 MB. This means that when the user double click on the icon, (s)he may have to wait a couple of seconds (depending on the disk speed and caching) before it is loaded and (s)he may thing that the computer is blocked and not working.
pyinstaller is multi-platform but not cross-platform. It means that I need to have two other development pcs, one with Win 7 and one with Win 11, to generate the exe file.
My third possibility was to generate a real python package that can be installed on all PC. And here the tricky point is, should it be installed with conda or with pip. I have a lot of confusion in mind about package building. I have seen and followed the tutorial on how to build a source and wheel python package on the python doc, but I don't know if it is the correct approach being my python environment inside anaconda.
I have seen that on git-hub you can automatically build an anaconda package starting from your python code and I would need to read the whole workflow documentation on how to do it because it doesn't look so easy to me. The drawback is that the clients PC have no access to GitHub, so I would need to manually copy the output package from a pc with internet access to somewhere on the segregated net and then let it install on all clients.
So, at the end of this long message, I hope I managed to describe my problem and I'm sure your answers will shed some light on it. I know that the question may sound trivial to the more advanced developers, but there are also newbies out here in need of good advices!
Thanks!
I've got a script that requires python3.7 or above.
I've got multiple systems each with different python versions. all of them have either python3.7 or python3.8 but just "python3" can also be python3.6.
Is there a way to make a shebang line take either python3.7 or python3.8? and fail if none exist of course.
I tried a billion of options and nothing works. I was hoping for something like:
#!/usr/bin/python3.7 || /usr/bin/python3.8
or
#!/usr/bin/python3.7
#!/usr/bin/python3.8
but nada.. I also couldn't google it up which kinda makes me sad but who knows maybe the answer is there somewhere and I'm just using a bizarre jargon
these are not systems I can change defaults on and installing python3.7 on each such setup is sadly not an option (would make life awesome).
The shebang simply needs to point to an actual executable.
That executable can be one which finds a suitable version of the Python interpreter; see for example the py tool which was popular on Windows for a long time but which is now also being made available on real computers. other platforms.
Ultimately, something somewhere needs to be on the user's PATH, which obviously you will not always have control over. If you are targeting unsophisticated users, perhaps look into providing your code in a compiled executable, a prepackaged Docker image, or something vaguely like that.
About a month ago, I used PyInstaller and Inno Setup to produce an installer for my Python 3 script. My AVG Business Edition AntiVirus just started complaining with today's update that the program has an SCGeneric Trojan Horse in the main .exe file used to start the program (in the folder created by PyInstaller that has all of the Python "guts"). At first I just thought it was a false positive in AVG, but submitting the .exe file to VirusTotal I get this analysis:
https://virustotal.com/en/file/9b0c24a5a90d8e3a12d2e07e3f5e5224869c01732b2c79fd88a8986b8cf30406/analysis/1493881088/
Which shows that 11 out of 61 scanners detect a problem:
TheHacker Trojan/Agent.am
NANO-Antivirus Trojan.Win32.Agent.elyxeb
DrWeb Trojan.Starter.7246
Yandex Trojan.Crypren!52N9f3NgRrY
Jiangmin Trojan.Agent.asnd
SentinelOne (Static ML) static engine - malicious
AVG SCGeneric.KTO
Rising Malware.Generic.5!tfe (thunder:5:ujHAaqkyw6C)
CrowdStrike Falcon (ML) malicious_confidence_93% (D)
Endgame malicious (high confidence) 20170503
Zillya Dropper.Sysn.Win32.5954
Now I can't say that these other scanners are ones that I have heard of before... but still I'm concerned that it is not just AVG giving a false positive.
I have submitted the .exe file in question to AVG for their analysis. Hopefully they will back off on whatever it is that they thought they were trying to detect.
Is there anything else I can do with PyInstaller to make it so that the .exe launcher that it created won't be considered a Trojan?
I was always getting some false positives with PyInstaller from VirusTotal. This is how I fixed it:
PyInstaller comes with pre-compiled bootloader binaries for different OSs. I suggest compile them by yourself on your machine. Make sure everything is consistent on your machine. For Windows 64-bit, install Python 64-bit. Download PyInstaller 64-bit for Windows. Make sure Visual Studio (VS) corresponding to your Python is installed, check below:
https://wiki.python.org/moin/WindowsCompilers
Compile the bootloader of PyInstaller on your machine with VS. It automatically updates the run.exe, runw.exe, run_d.exe, runw_d.exe in DownloadedPyinstallerFolder\PyInstaller\bootloader\Windows-64bit. Check below for more info on how to compile the bootloader:
https://pyinstaller.readthedocs.io/en/stable/bootloader-building.html
At the end, install PyInstaller. Within the PyInstaller directory, run
python setup.py install
I was able to submit the file in question to AVG's "Report a false detection" page, at https://secure.avg.com/submit-sample. I received a response back fairly quickly (I can't remember exactly how long, but it was less than a day) that they had analyzed my file and determined that it did not have a virus. They said that they had adjusted their virus definitions so that it would not trigger a false positive anymore. I updated my definitions and it was still triggering, so I contacted them again with my virus definition version, and I heard back that the version I had wasn't high enough - I think there was some delay on my definitions because I get them from a local server. But within a day I had the right version of the definitions and the false positive didn't trigger anymore.
So if you have a false positive with AVG, I would recommend this solution - fairly quick and easy to get a resolution to the problem.
I puzzled over this question for two days and finally found a problem with my application. The issue was with the application's icon.
Example for tkinter:
root.iconbitmap('./icon.ico')
When I removed this line of code, the false-positive Trojan was gone.
Also, make sure not to use --icon dependency when you are converting your .py file into .exe. Otherwise, this will cause the same false-positive Trojan detection.
I faced same issue for my small document register project code.
My temporary solution was to allow the app in windows defender and
other solution was to use the command pyinstaller filename.py instead of pyinstaller --onefile filename.py.
I dont know if it is correct. But it worked for me.
I searched many blogs for weeks. But I found nothing..
Today I found a way to convert py to exe without any virus errors.
Virus Total Report
So in this method you do not need to send any reports.. Actually It is very simple.
You need to install a module named Nuitka.
python -m pip install nuitka
Then you need to open command from from the file path. And use the command;
python -m nuitka --mingw64 filename.py
And that's all.
You can use the command
nuitka --help
You can find more at - Nuitka Guide
I had this same problem using python 3.8.5 and pyinstaller 4.5.1
In my case the first exe build was accepted by the antivirus (Windows Defender) but subsequent builds were flagged as having a trojan.
I solved it by using the pyinstaller --clean option every time I built the executable
Reverting back to PyInstaller 3.1.1 from 3.4 resolved similar issues on my end (at least temporarily).
As #boogie_bullfrog told, reverting to a previous version could be a solution. However I used *.spec file to store some data (like pictures and icons). I had the latest 3.5 version (August, 2019) and moving to 3.1.1 caused error when app was compiled (probably due to supporting Python 3.7).
So right now the easiest solution is to downgrade to 3.4
It supports specs from pyinstaller 3.5 and the onefile-app wasn't detected by Windows 10 built-in firewall
What I did was to solve this(make exe files non detectable as virus) was to downgrade pyinstaller by typing in cmd: pip install pyinstaller==4.1.0
And by the way it didn't work on 3.4.0 so I just randomly picked that version(4.1) and its pretty good looking so far :>
I'm pretty sure that it works on more than only that one version but that i experienced personally
Recompile and then reinstall your Pyinstaller bootloader manually.
This was a problem I had for a while, and my friend and I figured out this resolution with the help of many others. It almost always works to resolve the issue.
I posted the specific steps on my medium blog. Shared the link below, but the basic steps are as follows
Purge Pyinstaller Files within your Project and Rebuild
Uninstall Pyinstaller
Build a Pyinstaller Bootloader with your Compiler
Install the newly compiled Pyinstaller
Re-build your EXE with Pyinstaller, and make sure it’s not being be flagged as a virus
How to Resolve the Python Pyinstaller False Positive Trojan Virus
Part 1. Manually Compile your Pyinstaller Bootloader
Part 2. Working with Anti-Virus Developer(s)
I had a similar problem with a pyinstaller exe under Windows. Avira put that file into quarantine since it was considered potentially dangerous (due to heuristics, which means that some segments look typical for a virus, but no virus is actually found).
Keep in mind that the exe files you generate yourself are unique (as a consequence, the Avast scanner usually returns a message "you have found a rare file, we are doing a quick test", and delays execution for 15 seconds to perform a more thorough test).
My solution consists of some steps:
I have uploaded the exe to https://www.virustotal.com/gui/home/upload to check it with many scanners. If just one or two are detecting a virus, you should be on the safe side.
In order to make your local virus scanner accept the file, you can manually accept it for your computer, but this does not solve the underlying problem, so on other computers it would still be flagged as a virus.
Therefore I reported the file as false positive to Avira, which can simply be done by sending it by email. Other scanners have similar feedback lines. I got a feedback by email within one day that it is ok, and the scanner on my pc agrees with this now. Hope that this helps with the next iterations of my exe so that it stays clean.
Had the same problem today. Win8.1 would keep flagging .exe as virus. Updated to pyinstaller 5.7.0 but the issue persisted. Uninstalled pyinstaller 5.7.0 and did a fresh install. Strangely, Win8.1 isn't complaining anymore!
I would like the most advanced version of Python that still works on Windows XP. I need both Python 2 and Python 3.
What versions of Python will work on Windows XP?
I found that Python 2.7.9 and Python 3.4.4 are the newest versions of Python that work in Windows XP. I found this out through trial and error.
I've found a desperate guy (Daniel Pistelli) who didn't give up at the windows error dialog:
https://ntcore.com/?p=458
I like how he approaches the topic:
If we try to start any new application on XP, we’ll get an error
message informing us that it is not a valid Win32 application. This
happens because of some fields in the Optional Header of the Portable
Executable.
[...]
Fortunately, it’s enough to adjust the fields in the executable we want to start (python.exe), there’s no need to adjust the DLLs as well. If we try run the application now, we’ll get an error message due to a missing API in kernel32. So let’s turn our attention to the imports.
And then he goes on for another 5-6 screens. To sum it up, apparently you'll have to:
Modify the python.exe header,
Run a tiny Python script to remap some DLL calls,
Recalculate some binary hashes,
Create a fake kernel32.dll with certain calls forwarded,
Modify python37.dll to point to this fake thing,
and then you're all set. To be honest I couldn't quite follow (let alone verify!) some of the steps but it looks legit and there are links with Daniel's half-baked solutions for the harder parts, also a lot of Python sources explained. I will definitely give this thing a try.
In fact, here are the final scripts from his GitHub page:
https://github.com/dpistelli/xptmrt
Moral of the story: you can be crazy, but you'll never be dismantle-all-dlls-and-exes-and-open-hexeditors-and-disassemble-hashing-algorithms-and-mock-it-all-together-so-it-works-under-xp-crazy!
Someone had built Python 3.4.10, which is slightly newer than the officially prescribed Python3 v3.4.3/3.4.4 for Windows XP. Since it comes from the third-party (not the official Python website), use at your own risk,
-->Download<--
i tried 3.3.3 but i came up with an error message use 3.4.3/2.7.9 they are the only versions that work now sadly
There are several custom builds of Python >3.44 suitable for Windows XP. A poster at reddit has provided Python 3.55 here:
https://www.reddit.com/r/Python/comments/3tgi0t/python_35_x86_on_windows_xp/
Here is an XP compatible build of 3.6.15 source code only:
https://alex-free.github.io/winxp_python3.6.15/
At the MSFN forums someone has provided an XP compatible build of 3.8.1350 here:
https://msfn.org/board/topic/183741-python-3813-for-windows-xp-sp3/
Official website says about 3.4.10: https://www.python.org/downloads/release/python-3410/
Any of them, python is very platform independent. Some features might not work, but that would best be found in the documentation.
I have a program I've written in Python 2.7 on Windows, and I've been using py2exe with total success to make it into an exe (and associated files). However, a reasonable number of people who I want to use it are on Linux/OSX, and while some have been able to make the Windows version work with Wine, others have not been so successful. I've looked thoroughly into py2installer, py2app, freeze and others, but if I understand correctly (I am new to Python and very new to compiling) you need to run them on the system you want to compile them for, i.e. you can only compile for Linux on Linux and OSX on OSX. I don't want to distribute just the raw files because I want the source code to be obfuscated as it is inside a .exe, amd obviously not everyone has Python.
So, my question is: is there any way to compile for OSX or Linux, in Python, while on a Windows machine? And if not, what do you think the best alternative solution might be?
Code obfuscation is really not 'pythonic'. Even when packed into an .exe file, it's basically just the python interpreter and you source code (well, the .pyc files) zipped into one file. It is not as much as cross-compiling as it is about using a python package which does the thing you want (e.g, pack you code in a specific way) on linux.
Freeze will do this for you.
Most linux dists come with python built-in.
Get your linux box running! It's fun, useful, and you can always say 'On My Machine It Works!'. You can compile your code there / test your exe on Wine.
If for some reason you still can't get it to run, post a question!
Get Virtualbox, install Ubuntu in it, and build it "natively" in for Linux. These things work really well, and cross compilation is just asking for trouble. You're going to eventually need Linux to answer the support questions you'll get from these customers anyway! :(