I've tried PyInstaller, but it doesn't support Python 3.7. I'm using Python 3.7 features, so I don't want to downgrade to 3.6. How can I make my program a single-file, cross-platform executable?
Have you tried to use cx_Freeze? For Python 3.7, you need to apply the bugfix described in this answer by hand to your local cx_Freeze installation until a corrected version has been released.
cx_Freeze itself does not support building a single-file executable, but you can use further tools for this purpose as described here.
This depends on what you mean by "EXE file".
If you can jam all your source code into a single.py file then that would likely be the closest to a cross platform executable. It would just require having a python interpreter pre-installed on each OS.
If you are referring to a literal .exe executable file that works cross platform; for python programs this is impossible. Python compiles down to machine code in the same way that C and C++ do, which is platform specific. Unlike Java, which runs on a VM, if you wish to compile your python program into a single executable file, then the file will only work on whatever platform it was compiled on.
Related
I'm attempting to build TensorFlow's C++ library for Windows XP. While I've been able to build and use it on Windows 10, 32-bit XP isn't working. The background: I'm working on a COM module that calls fuctions from tensorflow.dll. My build environment:
Visual Studio 2017 15.7
CMake 3.11.1
TensorFlow 1.8
Windows 10
The sequence I use to build tensorflow.dll is:
Open "x64_x86 Cross Tools Command Prompt for VS 2017"
Try to force the use of functions availablbe in Win XP: set CXXFLAGS=/D_WINVER=0x0501 /D_WIN32_WINNT=0x0501
Add Git to path: set PATH=%PATH%;C:\Program Files (x86)\Git\bin
Fix CMake file for converting *.proto files to *.pb.h files as described here.
Configure CMake: cmake .. -A Win32 -T v141_xp,host=x64 -DCMAKE_SYSTEM_VERSION=7.0 -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=C:\Users\williams\AppData\Local\Continuum\Anaconda3\envs\tensorflow\python.exe -Dtensorflow_BUILD_SHARED_LIB=ON -Dtensorflow_BUILD_PYTHON_BINDINGS=OFF -Dtensorflow_WIN_CPU_SIMD_OPTIONS="/arch:IA32"
Build: cmake --build . --target tensorflow --config Release -- /fileLogger /m:1 /p:CL_MPCount=1
The last step also involves some manual labour as the build process doesn't copy .lib files from the 3rd part dependencies to where they are needed. For whatever reason, a bunch of INSTALL projects never get run so I had to do that manually each time the build would fail while looking for a missing lib file. Once that was done, the build completed successfully.
Next I copy my COM module (a DLL) and the TensorFlow DLL over to a Windows XP virtual machine for testing and try to register the COM module, but get an error LoadLibrary("MyDLL.dll") - The specified procedure could not be found. I don't know what procedure it is looking for, so the best I can offer is that Dependency Walker highlights WS2_32.DLL and tells me it can't find inet_ntop and inet_pton.
Any suggestions on how to build TensorFlow so that it doesn't use these two functions?
P.S. suggestions of "Stop using XP, its old and no longer supported" don't help here. Upgrading to Windows 10 is an absolute last resort because of the disruption it would cause at the facility where this software will be tested.
Edit 1:
These two functions inet_pton and inet_ntop were only used in one file that forms part of Google Cloud Storage support in TensorFlow. The build process generated a tensorflow_static.lib in addition to tensorflow.dll. Linking against the static version and adding a few dependencies that aren't included in tensorflow_static.lib got rid of the code using inet_* functions.
My COM module still isn't working on Windows XP though because the file tensorflow\core\platform\windows\env.cc uses functions like CloseThreadpoolWork, submit SubmitThreadpoolWork, etc. that were only introduced in Windows Vista. It looks like I'll have to replace them with something else, as I don't see an alternative implementation in TensorFlow.
Additionally, I found that tensorflow\contrib\cmake\CMakeLists.txt forces _WIN32_WINNT=0x0A00 and that CXXFLAGS is the wrong environment variable to use. Changing it to CMAKE_CXX_FLAGS at least gets my macro definitions included, FWIW.
It is almost impossible to port tensorflow to windows xp, because:
TF's platform depedent code requires some Windows APIs later than winxp such as Thread Pool API. This would possibly bypassed by using third party thread pool libs.
The nsync, protobuf and eigen, which are core parts of TF, use C++11 thread_local, which makes them unable to run-time load as dll, see https://learn.microsoft.com/en-us/cpp/parallel/thread-local-storage-tls?view=vs-2017 for details. This later feature can theoretically be replaced by old windows TLS API, which requires many modifications on TF's core framework.
Anyway, if you really need the xp support, good luck with that.
In the end I gave up on this as simply being impossible. Even replacing the thread pool functions with something from Boost didn't help. If someone else manages to get this working, I'll gladly accept that as the answer, but so far this looks impossible.
I'm trying to load a dll into my lua script and call the function. When I create the dll using GCC (under cygwin) and lua (5.2.4) I'm able to load the library & execute it without a problem.
However, when I create run the same script from SciTE, using Lua 5.1, the dll loads successfully. However, it does not execute. In the dll I'm trying to simply write two integers into a file.
t = package.loadlib("mylibrary.dll","myfunc")
t(23,45)
There are two questions here:
1. What format should the 'mylibrary.dll' be, for lua to understand and execute without problems - ELF or COFF.
2. Can I run dll (built under windows, obviously) under lua running on linux?
The question in your title seems to be very different from the cause of the problem you describe.
On the one hand, the format for dynamic libraries loaded by Lua is the format for the platform that the Lua code is running on. Just as you can't take a compiled Win32 executable and expect it to run on Linux, you can't take a compiled Win32 dll and expect it to load it on Linux. Obviously emulation tools like Wine exist, but those work by emulating Windows. You could run them within the emulator, but not outside of it.
But on the other hand, that is not the source of your problem. Your problem is that you're using a dynamic library that was built for one version of Lua with an application that was built for another version of Lua. That doesn't work; Lua does not retain compatibility between "minor" versions, only between revisions (Lua 5.1.3 vs. 5.1.4).
ELF or COFF, that isn't going to work.
I just installed msys2 and mingw64, with their development packages. I really need perl-Gtk3. Perl is msys2 and compiled with gcc-4.9.x, Gtk and friends are mingw and compiled with gcc-5.
Perl complains "Glib.c: loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xdd80080)" when building Glib. Should this work?
Thanks.
PS ... mingw-w64-x86_64-perl is simply unable to compile. And yes, I'm careful to use a mingw shell vs an msys shell.
Are you still having this problem? I have been able to build a Perl dev environment in MinGW64, current as of this time.
I have been able to build Perl Gtk2 / Gtk3 applications in that environment and the GUIs work. (Both Gtk2 and Gtk3 based). These applications are used in a production environment with several thousand desktop users. The application runs on OSX, Windows, and Linux, and can be packed into a binary for release as an "executable" for those operating systems. The details here are for the Windows version.
I do this by either installing the requisite system packages first with pacman, then as necessary rebuilding whatever system library packages that I may have modified, from source, using makepkg-mingw.
Then I build the requisite Perl modules using the CPAN shell, and the "look" command.
I use pkg-config to detect what library and header files are needed.
I then build (at minimum), the Perl Glib, Pango, Cairo, Gtk2, and Gtk3 modules using the perl Makefile.PL command.
The LIBS and INC options need to be added to that command to create a Makefile that includes the correct header files, and links to the correct libraries. The EXTRALIBS and LDLOADLIBS sections of the Makefile needs be correct.
Also ExtUtils::MM_Win32.pm ExtUtils::Liblist::Kid.pm needed to be edited due to the different archname reported by the MinGW64 perl.
I am only giving a general answer, because I was thinking offing a YouTube video on this. If this is a desired topic I will.
I want to use KDL (Kinematics and Dynamics Library) in robot control box. But robot control box uses SCons as their build system while KDL uses CMake.
It turned out that the control box doesn't have CMake installed. Should I install CMake in the control box? Or write SCons file for compiling KDL?
====================================================
My question is ambiguous. Sorry for that. And unfortunately, I cannot show the link of Control Box, it's not public. Here is link of KDL installation manual.
http://www.orocos.org/kdl/installation-manual
Let me make it more clear.
Forget all of previous question above and all about Control box, KDL. Let's say that you want to use one library. But the library can be built using CMake according to installation manual. Your PC doesn't have CMake installed but it has SCons, and unfortunately you should not install CMake on your PC.
If you can only use SCons, what can you do?
I know this situation is not usual, I want to know your opinion.
To answer your initial question: Yes, you should always try to install CMake, if that is a build requirement for you library and if you need to build that library from the sources.
To answer your later question: Replacing or rewriting the build system scripts is a major effort and not advisable. In general there is no script to convert build-systems. Such script might help to make the manual transformation. If you have a look at LLVM's effort to replace Autotools by CMake or Boost replacing it's own build system by CMake, you find out it takes several people several years and still not everybody is satisfied.
Often you don't need to build the library yourself. Either there are already built packages from the project directly of from your distribution (Debian etc. packages) or third party packagers like Mac Ports or NuGet.
In your case KDL provides Debian/Ubuntu packages.
Additional KDL is part of ROS, which is experimental in Homebrew for OS X.
there!
I'd like to execute example program, Surface_reconstruction_points_3.
I think the program needs additionally 3rd library, MPFI.
So I downloaded the library from http://mpfi.gforge.inria.fr/.
And I unzipped it at proper folder and linked it to the system path.
After configurating the example program using cmake-gui,
I found some error message, 'Could NOT find MPFI (missing: MPFI_LIBRARIES)'.
How can I install MPFI library in Window using visual studio 2008?
Since MPFI is a GNU library, it is completely supported on Windows.
CGAL provides this third-party libraries inside its installation, but Windows has its own replacement.
I installed this correctly with Visual Studio, but you need to uncheck those third-party libraries so CGAL won't mess with the own windows replacements.
Maybe doing this kind of installation isn't working well for all the sample codes inside the installation, but it works fine for development. I used CGAL without those third-libraries for Voronoi and 2D and 3D triangulation and it works fine.
For a clean installation, delete all you installed previously, make sure the new installation isn't messing with the bad previous installation.
EDIT:
About not using those optional libraries for Windows, I just received a similar mail through the CGAL mailing list and these could be the steps for newer versions of CGAL (>4.2):
You have to comment 3 lines in the CMake machinery:
In CGAL-4.1/CMakeList.txt you have to comment:
#list (INSERT CGAL_ESSENTIAL_3RD_PARTY_LIBRARIES 0 GMP MPFR)
#hide_variable(CGAL_ESSENTIAL_3RD_PARTY_LIBRARIES)
In CGAL-4.1/cmake/modules/UseCGAL.cmake you have to comment:
#use_essential_libs()
On the other hand, you can search on internet for precompiled versions of MPFI. For instance, you can find precompiled GMP, MPFR and MPFI for Windows on http://vegas.loria.fr/rs/ .