-
Notifications
You must be signed in to change notification settings - Fork 7
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
Released binary depends on libc and hardcodes the interpreter #7
Comments
@balsoft Thanks! I did not think about it... Will fix! One question: why do you suggest to use musl for static linking? Is it because it's more minimal and the executable will result in smaller size or because libc is not as portable? |
Statically linking to glibc is discouraged and not supported by upstream: https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged |
Just uploaded the statically linked binary to v0.2.2 release. I didn't use Nix, though, simply used musl wrapper for gcc:
I assume this method works too because both |
Thanks! |
Typically, when people distribute standalone binaries for Linux, they are expected to be statically linked and have no external library dependencies. However, it is not the case for the binary distributed with the release now:
This may cause issues when running on musl systems, or on systems without
/lib/ld-linux-x86-64.so.2
since then the hardcoded interpreter doesn't exist. One way to avoid such dependencies is to produce a statically linked executable linked to musl. E.g. with Nix:The resulting executable will be a bit larger (since it carries the relevant parts of libc with it) but it should work on a much wider set of systems, and do so more reproducibly and consistently.
The text was updated successfully, but these errors were encountered: