This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (18)
- # announcements (7)
- # asami (18)
- # babashka (15)
- # babashka-sci-dev (79)
- # beginners (61)
- # calva (4)
- # clj-kondo (23)
- # cljfx (16)
- # cljs-dev (6)
- # clojure (63)
- # clojure-bay-area (3)
- # clojure-europe (33)
- # clojure-nl (1)
- # clojure-survey (4)
- # clojure-uk (5)
- # clojurescript (37)
- # conjure (1)
- # cursive (8)
- # datahike (7)
- # datalevin (1)
- # datomic (30)
- # emacs (10)
- # events (2)
- # figwheel (2)
- # fulcro (20)
- # google-cloud (1)
- # lsp (6)
- # luminus (4)
- # malli (5)
- # music (3)
- # nextjournal (1)
- # off-topic (9)
- # other-languages (3)
- # pathom (16)
- # polylith (34)
- # re-frame (14)
- # reagent (19)
- # releases (6)
- # sci (2)
- # shadow-cljs (33)
Hey @rahul080327 @thiagokokada what is the reason to prefer musl static linking in native images over standard libc?
@retrogradeorbit Oh I found some docs here: https://github.com/clj-easy/graal-docs#static-linking-with-musl
Hey @retrogradeorbit essentially glibc cannot be fully static linked in a way musl can be, see this https://stackoverflow.com/a/57478728 pretty much the reason why musl was built. its a general problem for any native binaries, not specific to GraalVM native images
Rust for instance only does static linked binaries when used with musl+linux targets.
Or the other way to go is Go 😛 where none of the system libs are used in the same way other binaries link with
glibc static is something that kinda works most of the time, however may results in segfaults if you for example use a non-glibc distro or uses a glibc distro with an older version of glibc
yeah one of the main reasons for the segfaults being a mismatch of the ABI expectations the binary has with the kernel
You can have trully static binaries with glibc, but AFAIK this needs a specially compiled version of glibc with some flags that are completely unsupported by upstream
yeah... i dunno. I get that glibc static linking is a bit of a hack, and doesnt even work with all toolchains...
I've had quite some problems with the glibc-ed static versions of babashka and clj-kondo and will never go back doing that: those segfaults are a major headache.
but the graal static glibc image doesn't seem to match what that SO answer is talking about at all
Like, I may be wrong, but the static babashka with musl is smaller than the dynamically babashka with glibc
SO post may be talking in a more general sense of why static linking glibc is problematic?
> I don't see any lib deps, no dlopens, no nss, no iconv well thats some of the possible calls the binary may make, the graalvm one doesnt i guess?
> well thats some of the possible calls the binary may make, the graalvm one doesnt i guess? Yeah, Java itself may end up calling nss for example
For aarch64, musl is not supported. There I use the mostly static option: --static with dynamic glibc. that works fine.
yeah. and I experimented with musl versions and graal. And the new musl versions don't seem to work with graal at all
> For aarch64, musl is not supported. There I use the mostly static option: --static with dynamic glibc. that works fine. This is also a good point, static building glibc is not supported at all with GraalVM Native Image either
The documentation explicitly says: • Dynamically compilation • Static compilation with musl • Static compilation with glibc dynamically linked
This musl or dynamic documentation showed up around a year or so ago, before then the only option was
--static but this was in hindsight a mistake on their end.
yeah thats how we initially built the bb and kondo images with quite the suffering later on
its pretty much undefined behaviour when the image is "mostly static"
just curiously do you remember how the problem of static glibc manifested on other platforms?
@rahul080327 I refer to "mostly static" as a supported option explictly by the GraalVM docs. This is supported and gives defined behavior. https://www.graalvm.org/22.0/reference-manual/native-image/StaticImages/#build-mostly-static-native-image
don't remember, but I think it happened on systems that had a different (old?) glibc than the ubuntu I compiled it on
if i rack my brains it was debian 9 i think ?
yeah when it hit us it was very nasty head scratcher for us 😕
Another fun one: https://github.com/oracle/graal/issues/3737
Yeah, I took this issue exactly from Babashka source code (describing why we are using
Several mentions of android here: https://github.com/babashka/babashka/issues/241