Register the correct native library for Snappy, during native image generation #16069
Conversation
I take that back. Looks like this is indeed enabled in our CI runs https://github.com/quarkusio/quarkus/blob/main/.github/native-tests.json#L68 (I see |
| @@ -199,7 +200,7 @@ private void handleSnappy(BuildProducer<ReflectiveClassBuildItem> reflectiveClas | |||
| String path = root + dir + "/" + snappyNativeLibraryName; | |||
| nativeLibs.produce(new NativeImageResourceBuildItem(path)); | |||
| } else { // otherwise the native lib of the platform this build runs on | |||
| String dir = getOs() + "/" + getArch(); | |||
| String dir = OSInfo.getNativeLibFolderPathForCurrentOS(); | |||
There was a problem hiding this comment.
Is getOS and getArch still used?
There was a problem hiding this comment.
Good you asked :) I hadn't noticed that with this change, these methods will now be unused. I've updated this PR to remove them altogether.
…tive image generation
Fixes #16042
The commit here fixes the issue where the Snappy native library that was being registered as a native image resource was using the wrong resource path (it was using
org/xerial/snappy/native/Linux/amd64/libsnappyjava.soinstead oforg/xerial/snappy/native/Linux/x86_64/libsnappyjava.so). The commit here uses theOSInfoAPI from the snappy library to get hold of the correct path (just like we do in theio.quarkus.kafka.client.runtime.KafkaRecorder#loadSnappy()) and thus letting that API deal with the details.P.S: This
integration-tests/kafka-clientfails even with the latest released version of GraalVM, so this isn't related to any GraalVM dev version. It looks like this native-image tests isn't enabled in our CI, which is why this wasn't caught earlier. Perhaps we should enable these tests in our CI (as a separate PR)?