12

Possible Duplicate:
Is it feasible to compile Python to machine code?

Is it possible to compile Python code (plus its dependencies, plus the interpreter library) into a single, native Windows executable (with nothing else bundled along with it) from a Python file? (Kind of like how the GNU compiler for Java compiles Java into a native (humongous) executable, which contains everything in true machine code.)

If so, how would I go about doing this?

(Specifically, py2exe does not do what I want -- it includes the libraries inside a separate ZIP file, and it includes the interpreter as a separate DLL.)

Note 1:

To emphasize, I'm not asking for a "self-extracting archive", an "executable packer", or some other way of 'cheating' by bundling the files inside an exe -- I'm looking for something that genuinely converts Python into a native executable, like what GCJ does for Java.

Note 2:

Only if the above isn't possible:

Is it possible to at least generate a single executable from a Python code containing the interpreter bundled along with all the library dependencies, such that the resulting executable does not need to self-extract onto the target disk before running?

In this scenario, the 'compilation' requirement is relaxed: it doesn't matter if the code is actually compiled into machine code (it could simply be embedded as a text resource into the target executable), but the result must nevertheless be a single exe file [and nothing else] that can run standalone, specifically without needing to unpack/install anything onto the target disk before running.

Community
  • 1
  • 1
user541686
  • 189,354
  • 112
  • 476
  • 821

2 Answers2

7

Shed Skin can compile Python to C++, but only a restricted subset of it. Some aspects of Python are very difficult to compile to native code.

Taymon
  • 22,123
  • 8
  • 58
  • 80
  • +1 looks like it's exactly what I need; I'll definitely give it a try. – user541686 Jan 09 '12 at 09:36
  • Shoot... looks like the resulting executable still depends on `libpcre-0.dll`, `libgcc_s_dw2-1.dll`, and `libstdc++-6.dll`. Unless I can get rid of them by statically linking with GCC, this won't work... – user541686 Jan 09 '12 at 09:46
1

The short answer is no, and that is going to go for almost any language: any program you write is going to depend on some external libraries even if just the Windows system DLLs.

If you wrote a C program and compiled it with Microsoft's compiler you would still need the C runtime libraries to be installed. Chances are they already will be on most systems but it isn't guaranteed. Likewise even if you managed to compile a C Python interpreter statically linked to its libraries you still have to get the C runtime from somewhere.

What I suspect you are really asking is whether you can compile to a single .exe that depends only on libraries which you have a reasonable expectation of already being installed. So it all depends on what you are willing to consider part of the base system? Can you assume .Net framework 4 or Silverlight are installed? If so you might want to look at IronPython.

Likewise pypy can be built with either the Visual Studio toolchain or MinGW but I'm pretty sure in both cases you'll still need some external libraries at runtime.

Duncan
  • 79,697
  • 10
  • 108
  • 148
  • 1
    *you still have to get the C runtime from somewhere* I'm not sure if I get what you wanted to say here but you can obviously link statically to C runtime like to any other lib. – Piotr Dobrogost Jan 09 '12 at 11:58
  • What I was trying to say was that most compilers default these days to linking the libraries dynamically. I think Visual Studio still has an option to link statically to the C runtime but not all compilers will give you that option. Even if they do you there will still be some libraries where you don't get that option if the library is supplied as a DLL plus an import library. – Duncan Jan 09 '12 at 12:50
  • @Duncan I'm not a C/C++ guy, but I'm pretty sure you can statically link using GCC too, and I don't see why it wouldn't be possible. – Camilo Martin Jan 14 '13 at 02:51