embedded/graalvm: FROM scratch is missing dynamically linked libraries

[gmuth]

In Dockerfile, we could use "FROM gcr.io/distroless/java-base-debian12" to get required lib.so support.

In order to support a statically linked binary for "scratch usage" the native-image-maven-plugin configuration needs to be changed: --static --libc=musl ... However that currently causes build errors because musl is not installed in the builder image. Not sure how libz or libc can be supported here.

Another known issue is that currently only x86 is documented and officially supported for statically linked binaries. arm64 should not be left behind.

[mnriem]

@gmuth Just to clarify are you saying the guide is broken?

[gmuth]

The resulting docker image does not work as expected:

$ docker run --rm -it -p 8080:8080 graalvm
exec /helloworld: no such file or directory

The multi stage build builds a dynamically linked native executable. In order to run helloworld the linked libraries are also required:

# ldd /helloworld
linux-vdso.so.1 (0x0000ffff8a1df000)
libz.so.1 => /lib64/libz.so.1 (0x0000ffff8a171000)
libc.so.6 => /lib64/libc.so.6 (0x0000ffff89fc3000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff8a1a2000)

I suggest to split the example into separate examples:

• graalvm-fully-dynamic (FROM ? - distroless maybe)
• graalvm-mostly-static (FROM ? - image with libc only)
• graalvm-fully-static (FROM scratch)

See also graalvm example tiny-java-containers and graalvm linking options

[mnriem]

For now I have made it working by using a Debian base image, see https://github.com/piranhacloud/piranha-guides/commit/92d03c1e61d2eb8cee8170f463250ac7cda74e98 Feel free to open issues for the remaining work and if you can, consider doing a PR :)

[gmuth]

Looks good now! For now having one working build ("fully dynamic") is fine.

Another way to support different builds could be to provide different build files, e.g. pom.xml (files or profiles) and Dockerfiles.