Open dshynkev opened 3 years ago
The CI we use makes it pretty easy to add flags per OS - so we can just do static linkage for the Linux builds.
See https://github.com/tridactyl/native_messenger/blob/9adba18333251bea175232e6a709e755e950b63c/.github/workflows/compile.yml#L53 and https://github.com/tridactyl/native_messenger/blob/9adba18333251bea175232e6a709e755e950b63c/.github/workflows/release.yml#L75 (one day I'd like to work out how to merge these files; the duplication is silly).
A PR would be welcome - otherwise it'll just go on my (very long) todo list :)
Huge +1 to either fixing this with static linking, or providing Musl builds that are detected in the install script. I ran the install script and was trying to figure out why on earth :native
still failed - then I remembered, oh right, I'm on Void Musl. nimble build
and copying the resulting executable over top of ~/.local/share/tridactyl/native_main
, and otherwise making no changes after what all the installer script did, worked fine.
I think it's just a single line to change in the build scripts. I have never got round to doing it is all
with luck the blocks next release label will make it harder for me to forget about it. If you want it quicker than that, a PR would be welcome :)
Currently,
native_main
is dynamically linked withlibc
. This is almost never an issue, except formusl
users like me. Now, of course, I could just shut up and build my own executables, but, fortunately, static linkage is easy enough to propose universally:This increases the size of the binary slightly: 484K -> 523K. It should also help with reproducibility (though I doubt there are currently issues with that).
My main reservation with proposing this is that I don't know what this does on systems that aren't Linux, e.g. macOS, where static linking is unsupported. I assume that Nim does not statically link in such cases instead of building a fragile executable.