java.library.path is computed at build time

[cescoffier]

Describe the bug

So this is something that has changed "recently".
If you refer to https://quarkus.io/guides/native-and-ssl, we recommend to use:

CMD ["./application", "-Dquarkus.http.host=0.0.0.0", "-Djava.library.path=/work/lib", "-Djavax.net.ssl.trustStore=/work/cacerts"]

So basically, we configure the java.library.path are runtime, pointing to the right directory (in my case the directory containing the sunec file)

Except that this does not work anymore. For example, if my application prints the value of the
java.library.path system property, it gets:

Lib: /Users/clement/.sdkman/candidates/java/19.2.0.1-grl/jre/lib:.

So basically, the location on my host.

Expected behavior

The java.library.path should not be computed at build time, or at least should be configurable at runtime.

To Reproduce

1. Take the rest-client quickstart, build the native image for containers:

 mvn package -Pnative -Dquarkus.native.container-build=true

2. Use the docker file provided in https://quarkus.io/guides/native-and-ssl#working-with-containers

FROM quay.io/quarkus/ubi-quarkus-native-image:19.2.1 as nativebuilder
RUN mkdir -p /tmp/ssl-libs/lib \
  && cp /opt/graalvm/jre/lib/security/cacerts /tmp/ssl-libs \
  && cp /opt/graalvm/jre/lib/amd64/libsunec.so /tmp/ssl-libs/lib/

FROM registry.access.redhat.com/ubi8/ubi-minimal
WORKDIR /work/
COPY target/*-runner /work/application
COPY --from=nativebuilder /tmp/ssl-libs/ /work/
RUN chmod 775 /work
EXPOSE 8080
CMD ["./application", "-Dquarkus.http.host=0.0.0.0", "-Djava.library.path=/work/lib", "-Djavax.net.ssl.trustStore=/work/cacerts"]

I've overriden the content of the Dockerfile.native with this

3. Build and Run as container

Workaround

Fortunately, there is a workaround. Instead of configuring the java.library.path, copy the required library is the cwd (/work/ in the docker file mentioned above).

[jaikiran]

I've issued #5895 to fix this.

[Sanne]

I'd be cautious in not applying a fix. Why should we support a change of libraries after build?

I'd think a better solution is to ensure you're building on the correct target platform - your workaround mentions copying the library to the target, isn't that the right approach?