Question about musl static binaries (I still not fully understand it ๐
)
Should my program (clojure-lsp) that already compiles linux static with the -H:+StaticExecutableWithDynamicLibC change to --musl , what are the tradeoffs?๐งต
See latest issue in the borkdude/jet repo, that might give you an idea ๐
@borkdude and I had a lot of fun over this ๐
@ericdallo in a gist, when you use StaticExecutableWithDynamicLibC its compiling the binary with syscalls stubbed out to glibc which it may or may not use. So when you run in a non glibc OS like alpine and the binary wants to make such a call, it will segfault and there no saying when it may happen. Hence we use the musl lib which is a full c stdlib impl designed to be static linked unlike glibc
the segfault manifests as a cryptic file not found
also when it cannot find the .so file
@rahul080327 could you take a peek at that latest jet issue?
having a look
@borkdude I took a look and it seems to be the same issue on clojure-lsp right? jet didn't have the static binary compiled with musl too, right?
exactly
I see, so it just confirm that using musl is always the safest option right? I always thought that but on some conversation recent on some thread, I (miss?)understood that there are cases where musl doesn't work but glibc works, is that right?
I haven't encountered a situation where a musl compiled binary doesn't work and glibc did work better
Good, so that's sounds safe enough to me
thank you!
apart from the stack size issue i think
There is one caveat with musl concerning the stack size
my workaround for that is this: https://github.com/borkdude/jet/blob/12dc569e2b48a97db016719d93e424c645ac3453/src/jet/main.clj#L149-L171
and:
BABASHKA_STATIC=${BABASHKA_STATIC:-}
BABASHKA_MUSL=${BABASHKA_MUSL:-}
if [ "$BABASHKA_STATIC" = "true" ]; then
args+=("--static")
if [ "$BABASHKA_MUSL" = "true" ]; then
args+=("--libc=musl"
# see
"-H:CCompilerOption=-Wl,-z,stack-size=2097152")
else
# see
args+=("-H:+StaticExecutableWithDynamicLibC")
fi
fi So what I do is set the stack size to 2mb and run the main program within a thread
good to know about this workaround, will use it too