Today all our infrastructure is based on python 2.7.2 and we want to use it on Windows10 ARM64 machine as well. But in the link below, you can see that the ARM64 compiler is included in VS2017 and not in previous versions.
So no chance to compile python 2.7 for windows10 ARM64?
Did someone try that?
What are your suggestions?
https://wiki.python.org/moin/WindowsCompilers
I've just ran into this, I know it's a little late but never late than never.
I'm just in the process of building Python 2.7 for Windows aarch64. It seems to work with some minor patches (mainly required to get it to compile with MSVC2017, since 2.7 is usually compiled on the ancient MSVC2008, which doesn't have a native aarch64 compiler).
The interpreter seems to work just fine but I still need to finish building all the included modules before I can say it's ready. Right now I got around half of them running and I hope I can get the rest working soon. The biggest pain is going to be ctypes, I think I'll get it working eventually but issues are expected.
If this is still relevant please post a reply and I'll share it when I'm done building everything.
EDIT: Just finished, download Python 2.7 ARM64 and a bunch of other ARM64 open source programs and libraries from here -
https://mega.nz/#F!PclhDIRB!-yhBZ6UM7S596ijNU3dx0A
Related
I have MacBook Air with m1 chip and tried to install SFML according to the instructions on the official website however I can not compile the project for example
enter image description here
EDIT: I moved the Xcode app act via rosetta 2 and now it works I would love to know if there is a solution that will activate it natively
The error you are receiving is telling you that the version being linked is for MacOS on x32_64, while trying to compile for arm64. This is incompatible, given they're two different platforms.
Are you compiling SFML from source? It doesn't look like SFML has precompiled binaries for MacOS-arm64, but the source code does have arm compatibility. Compiling from source would be operating system agnostic as long as everything is there (and supports arm64.) SFML has an article on how to compile from source with CMake: https://www.sfml-dev.org/tutorials/2.5/compile-with-cmake.php
While I can't guarantee this will fix your issue, it's definitely worth a try if you haven't yet.
The reason using Rosetta made this work is because Rosetta emulates some parts of x32_64. Running these apps in Rosetta would essentially be the same as compiling your project on an Intel based Mac.
I found the solution if it can help some, just make your pc believe that you have an intel chip, by adding /usr/bin/arch -x86_64 before your order.
example:
/usr/bin/arch -x86_64 clang main.c -lcsfml-graphics -lcsfml-system
Interesting delema.
Trying to compile Qt program where Qt is build from source on 18.04 64-bit and run it on 14.04. The interesting part is trying to identify which libraries I need this time. The C++ ABI has changed.
Looking to see if anyone else has done this recently? Which libraries do I have to bring along? Yes, I know about ldd and readelf and have spent days trying this in various VMs. The problem is once you start bringing the C++ stuff over (because the ABI has changed yet again) you get to a point where your VM won't reboot.
Please don't suggest snappy, flatpak or one of those other new "container" solutions. Already wasted 3+ days on snappy. It's architecture specific and only supports building on 14.04 when it comes to Qt, at least the deployqt tool to make an AppImage does.
Did this years ago with this very program. Built a debian which would install on both 64-bit and 32-bit for every version from 12.04 to 15.04 including the short lived .10 and odd year versions.
I tried compiling QT with C++11 standard, but, it will no longer compile with that standard.
The incompatible ABI is the real killer.
It is more than one program so the hack of a shell script using LD_LIBRARY_PATH would bring considerable difficulty.
Appreciate insights.
Thank you.
Please always develop applications on the oldest distribution you still want your application to run on. For example, if you want your application to run on all currently still-supported versions of Ubuntu, then develop your application on Ubuntu 14.04 and do not install any newer compilers or libraries than what it comes with.
This is how "backward compatibility" works.
As title,
Build successful, but the exe can't run. can not found msvcr100.dll.
I can put msvcr100.dll with exe in the same dir, the exe can run.
But I just want only one exe file.
Anyone know how to do?
Has solved. This is a bug of pyinstaller3.2, the new in the git has solved this bug. Down the newest source in the github, erverything works fine.
Has solved. This is a bug of pyinstaller3.2, the new one in the git has solved this bug. Down the newest source in the GitHub, everything works fine.
This is correct, I cant tell you how much that answer helped me out. I have been trying to build a single exe Exploit to execute on Windows XP with-out it crashing for my OSCP Labs/Exam. I followed so many tutorials and nothing seems to work. I was able to build the EXE but could not get it to run under a single EXE.
If anyone who reads this is getting "This Program cannot be run in DOS mode" try running it from another machine with the same build (Windows XP). There is not much info out there on how to solve that from a Reverse Shell on a End Of Life Operating System using an EXE exploit built with Pyinstaller. (Lots of Trial and Error and determination)
Microsoft Visual C++ 2008 Redistributable Package (or some other version depending on python version) is needed in any case, python27.dll requires it
I was also receiving an error about msvcr100.dll when ran from the GUI on my build machine(WinXP SP2). This is corrected in the 3.3 Dev version on GitHub.
I installed the C++ 2008 Package but this didn't solve my problem when I re-built the EXE, the 3.3 Dev Pyinstaller was the solution.
What I did was:
Zip down the Dev version of Pyinstaller 3.3 Dev(GitHub) is the newest for 11/14/16 that I could tell. Make sure you have Python 2.7.x (I used 2.7.11) and pywin32 installed that matches (Python 2.7.x) version. (And it does matter if its 64-bit or 32-bit) Use the setup.py to install Pyinstaller, make sure you do not have a previous version already installed, if so use pip or etc. to remove. I installed with pip first and this was my whole issue.
I was able to get all of my 32-bit Single EXE Exploits to run on 64-bit/32-bit Windows machines up to Windows 10.
Once that is completed, make sure Pyinstaller is in your $PATH and follow the standard tutorials on creating a --onefile EXE. Copy to your Windows Target machine and it should work with-out error. I did not need to pull any dependencies over but you may have to include some with the --hidden command. Its greatly detailed in the Pyinstaller documentation on how to include hidden .dlls
If this still doesn't work for you try using py2exe. Its a little more complicated but it your determined you will figure it out.
If you have code written in python 2.x.x and 3.x.x you can have multiple environments of Python and have Pyinstaller installed in each. This is in the documentation as well.
Thank you jim ying. Your 2 sentence answer was exactly what I needed.
Im currently building a module with boost python and I cant get it to build against the correct version of python(I need it to build against 2.6). The first thing I tried was setting my PATH to that of the version of python I'd like to install, but that built a module that would only run on the default system version, 2.7. Next I tried adding --with-python-version=2.6 as an argument for bootstrap but that didnt work either.
I'm new to c++ and I'm building someone else's code so apologies if there is a blindingly obvious answer
I don't know if this is what solves your issue, but it sounds like something I had dealt with when building another boost project. It would constantly find the wrong python installation no matter what I do. Namely, it always wanted the system python. I addressed it by telling it to look at another INCLUDE location:
cmake -D PYTHON_INCLUDE_DIR=/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Headers
I am trying to deploy my application from development environment to users' computer, but I have some issues.
First, I compile and run it on my development computer (higher version Ubuntu11.04):
Ubuntu11.04$ make
Ubuntu11.04$ ./MyApp
Program runs okay.
Then I copied the binaries MyApp to two lower-version machines (users' computer):
Ubuntu10.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
Ubuntu8.04$ ./MyApp
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./MyApp)
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./MyApp)
However, if I compile the source code on Ubuntu10.04, and run it:
Ubuntu10.04$ make
Ubuntu10.04$ ./MyApp
Program runs okay.
What should I do with this? When I compile it in development environment, how can I set the version number of the used library? I'm not directly using GLIBCXX, I think it's being used implicitly somewhere in my project.
Thx a million.
Peter
Did you see Link with an older version of libstdc++
I have never installed an older version of g++, but I have included a libstdc++.so in my release and that has worked for me. Best solution I have seen is get your development stuff to work on the oldest possible system. We compile some stuff on Red Hat 9 and it work on everything, but it can be any major issue building on old machines as you say.
You have built on version N, and tried to deploy on version M, M<N. You will need to get the deployment computer upgraded, or learn the procedure to compile and link targeting an older version. Since the problem lives in libstdc++, I'm afraid that my advice is to downgrade your entire dev system or upgrade the target, libstdc++ is not easy to deal with. Another answer here has someone's recipe.
Keep in mind that the Ubuntu/Debian community is optimized for open source. From their point of view, the solution to this is for you to distribute source code with the auto* tools, and let the user built it for him or her-self. They don't stay up late making this easy for you.
Here in the evil world of closed source, we keep around VMs running all sorts of old linux distros just so that we can build a single binary that runs in many places.