Use a statically linked libc

[mboes]

sparkle package computes the transitive closure of all runtime dependencies (.so libraries) and copies those dependencies into the .jar file for the app. In this way, the app is self-contained. However, there are exceptions: libc.so and libpthread.so are not included in the closure. The reason is that using our own libc.so, which may different from that of the target system, sometimes leads to load time failure.

But introducing impurities in the transitive closure is not without risks: we won't notice until runtime whether one of the libraries we built against actually requires a newer/older libc than the one on the target system. Further, it increases the surface area for things to go wrong: whereas an app might be tested with one libc, it's possible that results end up different with another libc.

So the alternative is to statically link libc. It is possible to statically link glibc, despite a former maintainer's extremist views on the matter. But an alternative here is also to use a stripped down libc instead, e.g. musl. In this way, all dynamic libraries are part of the closure, and whatever can't (i.e. libc) is statically linked anyways.

[domenkozar]

As I'm also looking into this for https://github.com/input-output-hk/cardano-sl, if you're interested let's talk :)

[robinbb]

@domenkozar Which part of the above are you interested in? Replacing libc with musl? Statically linking libc, generally? Or, solving the problem of shipping the transitive closure of dependencies of a binary? Are you seeking a Linux-only solution?