michelin / kafkactl

Kafkactl is the CLI linked with Ns4Kafka. It lets you deploy your Kafka resources using YAML descriptors.
Apache License 2.0
10 stars 5 forks source link

Kafkactl cannot be executed in a Alpine Docker image #129

Open nil-malh opened 5 months ago

nil-malh commented 5 months ago

Describe the bug

Kafkactl will produce a segmentation fault when running the native-image in a Alpine Docker image

/# kafkactl
Error relocating /usr/local/bin/kafkactl: __strdup: symbol not found
Error relocating /usr/local/bin/kafkactl: __strtok_r: symbol not found
Error relocating /usr/local/bin/kafkactl: __isnan: symbol not found
Error relocating /usr/local/bin/kafkactl: __isnanf: symbol not found
Segmentation fault

To Reproduce

Expected behavior

Should work as expected without the segmentation fault

Environment (please complete the following information):

Steps taken to try and solve the problem

The issue is mainly due to Alpine not using glibc but musl, and so some symbols are missings when running the native-image.

The easiest way to fix this issue is to use GraalVM Static Native Executable see here

As explained in the documentation :

A static native executable is a statically linked binary that can be used without any additional library dependencies. A static native executable is easy to distribute and deploy on a slim or distroless container (a scratch container). You can create a static native executable by statically linking it against musl-libc, a lightweight, fast and simple libc implementation.

In order to apply this to kafkactl some tinkering is required :

Hey everyone :) As @ dainiusjocas mentioned, this problem started happening due to a change in the gcc musl toolchain build process that started treating relocations in a read-only section at runtime as an error rather than a compile time warning. I don't think we can report this issue to the musl toolchain developers - this was probably an intended change from their side.

The reason why it fails with native-image is because a read only section that gets placed in a read only segment at runtime, .svm_heap, has relocations that can only be resolved at program startup.

I don't see a trivial way to get rid of these relocations (I assume most of them come from method address relocations, for e.g. for the vtables).

As a workaround, it's probably best to use GCC 10.2.1 for cross-compiling to musl. Alternatively, there may be a ld option that can prevent the linker from failing due to these relocations, but I'm not sure which one it is exactly :/

Tracked internally by GR-24601

Originally posted by @gradinac in https://github.com/oracle/graal/issues/4076#issuecomment-1304037035

The latest functional version is https://more.musl.cc/10.2.1/x86_64-linux-musl/x86_64-linux-musl-native.tgz