test.lua fails to load because of being unable to load libjimage.so

[PureTryOut]

I'm working on getting this package into Alpine Linux but I'm having trouble building and running it. See https://gitlab.alpinelinux.org/alpine/aports/-/issues/16606 for our downstream discussion on it.

Basically it fails to compile for me:

+ JAVA_HOME=/usr/lib/jvm/java-21-openjdk
+ CC=gcc
+ CFLAGS='-Os -fstack-clash-protection -Wformat -Werror=format-security'
+ LDFLAGS='-Wl,--as-needed,-O1,--sort-common -Wl,-z,pack-relative-relocs'
+ gcc -shared -fPIC -I/usr/lib/jvm/java-21-openjdk/include -I/usr/lib/jvm/java-21-openjdk/include/linux -Os -fstack-clash-protection -Wformat '-Werror=format-security' -Wl,--as-needed,-O1,--sort-common -Wl,-z,pack-relative-relocs -o lujavrite.so lujavrite.c
Error occurred during initialization of VM
Unable to load jimage library: /usr/lib/jvm/java-21-openjdk/lib/libjimage.so

Strangely enough as can be seen in the linked thread someone else got it compiling but then failed on the same library when actually running the test file.

[mizdebsk]

I've just tried with alpine:latest container image and I can build lujavrite and run its tests with the following sequence of commands:

apk add openjdk21-jdk git gcc lua5.4-dev musl-dev
git clone https://github.com/mizdebsk/lujavrite
cd ./lujavrite
export CC=gcc
export JAVA_HOME=/usr/lib/jvm/java-21-openjdk
export CFLAGS='-Os -fstack-clash-protection -Wformat -Werror=format-security -I/usr/include/lua5.4'
export LDFLAGS='-Wl,--as-needed,-O1,--sort-common -Wl,-z,pack-relative-relocs'
./build.sh 
export LD_LIBRARY_PATH=$JAVA_HOME/lib/server
lua5.4 test.lua

For running tests I had to set LD_LIBRARY_PATH to $JAVA_HOME/lib/server, otherwise the "Unable to load jimage library" error happens. Without LD_LIBRARY_PATH, the ldd /usr/lib/jvm/java-21-openjdk/lib/libjimage.so command fails like in the linked gitlab issue. Why - I don't know, but I would suspect some musl vs glibc dynamic linker incompatibility.

[mizdebsk]

After digging a bit more this indeed looks like a problem with musl dynamic linker. Apparently even the java command from the OpenJDK port for musl re-executes itself after setting LD_LIBRARY_PATH: Reference: https://www.openwall.com/lists/musl/2020/06/04/11

[bratkartoffel]

I don't know, but couldn't you set the LD_LIBRARY_PATH prior loading the java library? Somewhere around https://github.com/mizdebsk/lujavrite/blob/master/lujavrite.c#L48

This should make it work for musl and not break it for other libc implementations.

[mizdebsk]

I don't know, but couldn't you set the LD_LIBRARY_PATH prior loading the java library?

lujavrite is just a library, modifying process environment would be asking for problems - there's no way of doing that in a multi-threaded process without possibly affecting other threads. Then, I'm not sure if it would work at all - musl dynamic linker may apply LD_LIBRARY_PATH during process startup.

Maybe there are better ways to make this work with musl, but searching around for "Unable to load jimage library" reveals that others have similar issues with OpenJDK and musl.

I'm open for ideas and patches, but I don't see any good solution to this issue. As a workaround, whoever is creating the process that runs lujavrite should set appropriate LD_LIBRARY_PATH on musl-based system.