-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem using PyInstaller on Alpine (musl) #48
Comments
Hi Tom, greating talking with you at DockerCon. For this to work we might just need to symlink I was going to test this. But I can't actually find the |
Ah, it's on my own repo - here https://github.com/tomdee/calico-docker/tree/alpine-build I'll try your fix when I get a chance, but I now realize that the binary that Pyinstaller builds will be dynamically linked with the musl libc and I want to run the binary on other linuxes. So my hope of bulding in an Alpine linux container is probably a non-starter. |
Symlinking ld-musl-x86_64.so to /bin/ldd didn't work. I might try a glibc version of alpine |
After reading through #11 I see that trying to use glibc would be the wrong approach - I would still be bundling a python binary that depends on musl. FTR - the problem can be repro-ed by checking out the above code (https://github.com/tomdee/calico-docker/tree/alpine-build) and running make binary |
I've just another quick look at this and I suspect it could be an issue with the Pyinstaller code. Possibly the way they are looking at libs is incompatible with the dynamic behaviour of ldd on alpine The Pytinstaller code I've looked at is here https://github.com/pyinstaller/pyinstaller/blob/dd1c17e7874e7b066d44b9fe4eaca80cb1baf96f/PyInstaller/depend/bindepend.py#L552 |
Ah yes - so the problem is ldd producing output like this
Pyinstaller is trying to find the path to |
It seems I can fix it with |
Interesting. Thanks for the workarounds. Does Pyinstaller pull in binaries that are compiled against glibc and looking in /lib64? If Pyinstaller is looking at |
I'm going to close this issue as there sounds like a workaround. Let me know if otherwise and I'm happy to try and debug some more. |
The workaround isn't pretty, but does seem to work - FTR I'm using it here projectcalico/kube-controllers#10 |
I found a good solution.
The end result is I can create single file Python apps that work on other Alpine hosts (even non-Docker ones). I packaged all this up for easy explanation and re-use https://github.com/six8/pyinstaller-alpine |
@six8 than you for that workaround! I don't think I would have been able to figure that one out myself. BTW, I don't know if something was fixed in alpine:3.4, but so far, my pyinstaller bundled app does not segfault when python is installed via APK vs. using the official python docker image as you suggested. It might be worth retrying in alpine:3.4. This lets me have both python 3 and python 2 installed in a single pyinstaller container and decide which version of python to bundle the app with at runtime. |
If you use setup.py (instead of requirements.txt) and/or python 3.5 - I am pushing a version for that nerdwaller/pyinstaller-alpine:py3 It still defaults to |
On project calico, we currently use a ubuntu base image but I'd love to swithc to alpine. The current stumbling block is with PyInstaller which doesn't seem to be compatible with libc.musl
The output I'm seeing from PyInstaller is below, and can also be seen at https://semaphoreci.com/calico/calico-docker--5/branches/alpine-build/builds/1
You can repro by cloning calico-docker, checking out the alpine-build branch and typing make binary
The text was updated successfully, but these errors were encountered: