Skip to content

[Documentation] [Request for a new FAQ entry] Explain the use case(s) for "mostly static native executable" at https://www.graalvm.org/latest/reference-manual/native-image/guides/build-static-executables/ #6767

Open
@rubyFeedback

Description

@rubyFeedback

Hey there GraalVM team,

To preface: I was able to build a statically compiled native image some months ago, using glibc already, so all that works fine.

At the document here:

https://www.graalvm.org/latest/reference-manual/native-image/guides/build-static-executables/

The steps are explained.

I just re-read it. But after reading it, I wonder about the use cases for a mostly statically compiled native image.

"With GraalVM Native Image you can build a mostly-static native executable that statically links everything except libc. Statically linking all your libraries except libc ensures your application has all the libraries it needs to run on any Linux libc-based distribution."

However had, I am still unsure what the main differences / benefits are. So in my simple brain, I have it now associated that I want a fully statically compiled application, so I am never dependent on libc. I suppose this is not entirely correct or complete.

Could someone perhaps consider adding a new FAQ entry there, e. g. use cases for either these two variants? Or in other words, why we need a mostly statically compiled native executable, as opposed to a fully statically compiled one? Because the latter one appears to be more useful to me, so maybe I got something wrong.

(PS: Also full musl support would be interesting one day, perhaps the resulting binary would be smaller. But I digress here.)

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions