3 ms·

The only problem I have found with Pyinstaller is that their "standalone" builds still depends on certain libraries that will change with the version of Python

The only problem I have found with Pyinstaller is that their "standalone" builds still depends on certain libraries that will change with the version of Python in the host OS, such as the glibc library, or others. The proposed solution by Pyinstaller is to build your program in the "oldest" version you support, which is silly compared to build systems like Go's, which are true standalone. Having said that, I'm curious about this solution, since it seems to claim a true standalone build...

physicsguy 5y ago
Go binaries are often not truly standalone. You can certainly make static Go binaries that don't use cgo, but you can't then use standard libraries which rely on it.
- curryst 5y ago
  I believe that if you use MUSL for libc, you can statically link libc into the binary. That should make the standard library all statically linkable, I'm not aware of any other C dependencies (although I could very well be wrong).
zvr 5y ago
The other issue with PyInstaller is that, by default, it includes all dynamic libraries that the Python interpreter has on your machine. It makes sense, it needs an interpreter and collects what is needed for it to run. Unfortunately this might include libreadline.so, which is licensed under GPL, making your resulting executable unable to be under a proprietary license. There are ways to solve this issue, but one has to search and read documentation (and code, in my case -- when I was researching it the docs were not clear).
- pansa2 5y ago
  > [PyInstaller] includes all dynamic libraries that the Python interpreter has on your machine. Yes - and last time I used it, it created either a large folder or a compressed archive containing all of those libraries. Only the latter gives a truly standalone executable - but it's very slow to start up because it has to extract the archive to disk every time it runs. It sounds like Nuitka has a solution for this problem, at least on Linux: "[the binary] will not even unpack itself, but instead loop back mount its contents as a filesystem".
  - XzAeRosho 5y ago
    Indeed it does. The only downside of this is that the resulting binary is (at least in my case) almost tripled in size compared to Pyinstaller (5MB vs 14.6MB). But I can live with that. Still doesn't statically link C libraries (or at least I didn't find the setting for it), or other libraries for that matter. Pyinstaller binary build depends only on: libdl.so.2, libz.so.1 and libc.so.6. Nuitka binary build depends on: libdl.so.2, libz.so.1 and libc.so.6 AND libpthread.so.0 (for the loopback mounts I suppose). The one that always creates problems is libc.so.6, which usually is not present 4 year old systems...
vascocosta 5y ago
Hmm, with Pyinstaller I generate true standalones which require no libs at all, nor Python to be installed on the host system. Do you use the --onefile option? As an example, here's a little project which I also release as a single binary file that works everywhere I've tested, with no deps: https://github.com/vascocosta/glueather https://github.com/vascocosta/glueather

physicsguy 5y ago

Go binaries are often not truly standalone. You can certainly make static Go binaries that don't use cgo, but you can't then use standard libraries which rely on it.

curryst 5y ago
I believe that if you use MUSL for libc, you can statically link libc into the binary. That should make the standard library all statically linkable, I'm not aware of any other C dependencies (although I could very well be wrong).

zvr 5y ago

The other issue with PyInstaller is that, by default, it includes all dynamic libraries that the Python interpreter has on your machine. It makes sense, it needs an interpreter and collects what is needed for it to run. Unfortunately this might include libreadline.so, which is licensed under GPL, making your resulting executable unable to be under a proprietary license. There are ways to solve this issue, but one has to search and read documentation (and code, in my case -- when I was researching it the docs were not clear).

pansa2 5y ago
> [PyInstaller] includes all dynamic libraries that the Python interpreter has on your machine. Yes - and last time I used it, it created either a large folder or a compressed archive containing all of those libraries. Only the latter gives a truly standalone executable - but it's very slow to start up because it has to extract the archive to disk every time it runs. It sounds like Nuitka has a solution for this problem, at least on Linux: "[the binary] will not even unpack itself, but instead loop back mount its contents as a filesystem".
- XzAeRosho 5y ago
  Indeed it does. The only downside of this is that the resulting binary is (at least in my case) almost tripled in size compared to Pyinstaller (5MB vs 14.6MB). But I can live with that. Still doesn't statically link C libraries (or at least I didn't find the setting for it), or other libraries for that matter. Pyinstaller binary build depends only on: libdl.so.2, libz.so.1 and libc.so.6. Nuitka binary build depends on: libdl.so.2, libz.so.1 and libc.so.6 AND libpthread.so.0 (for the loopback mounts I suppose). The one that always creates problems is libc.so.6, which usually is not present 4 year old systems...

vascocosta 5y ago

Hmm, with Pyinstaller I generate true standalones which require no libs at all, nor Python to be installed on the host system. Do you use the --onefile option? As an example, here's a little project which I also release as a single binary file that works everywhere I've tested, with no deps: https://github.com/vascocosta/glueather https://github.com/vascocosta/glueather