Library path not working ?

[ed03875]

Question

We are switching from AdoptOpenJDK OpenJ9 Java 8 to Temurin HotSpot Java 8. We are noticing that Hotspot does not use the Unix environment variable LD_LIBRARY_PATH and also ignores -Djava.library.path. This seems to be a significant difference between the two JVMs if it is not a bug. Have others reported this problem ?

Java version:

Paste the entire output of java -version. java -version openjdk version "1.8.0_312" OpenJDK Runtime Environment (Temurin)(build 1.8.0_312-b07) OpenJDK 64-Bit Server VM (Temurin)(build 25.312-b07, mixed mode)

Your operating system and platform: Linux version 3.10.0-862.3.2.el7.x86_64 #1 SMP Mon May 21 23:36:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[karianna]

Hmm, my spidey senses wonder if this is related to some recent fontconfig detection issues we've seen.

[karianna]

@ed03875 - Can you try with the very latest 8u322 and also give us some context as to what you're trying to load?

[jerboaa]

@ed03875 How would I reproduce this? It's respecting LD_LIBRARY_PATH setting just fine:

$ LD_LIBRARY_PATH=foo ./jdk8u322-b06/bin/java -XshowSettings:properties -version 2>&1 | grep -C10 java.library.path
    file.separator = /
    java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
    java.awt.printerjob = sun.print.PSPrinterJob
    java.class.path = .
    java.class.version = 52.0
    java.endorsed.dirs = /disk/openjdk/builds/jdk8u322-b06/jre/lib/endorsed
    java.ext.dirs = /disk/openjdk/builds/jdk8u322-b06/jre/lib/ext
        /usr/java/packages/lib/ext
    java.home = /disk/openjdk/builds/jdk8u322-b06/jre
    java.io.tmpdir = /tmp
    java.library.path = foo
        /usr/java/packages/lib/amd64
        /usr/lib64
        /lib64
        /lib
        /usr/lib
    java.runtime.name = OpenJDK Runtime Environment
    java.runtime.version = 1.8.0_322-b06
    java.specification.name = Java Platform API Specification
    java.specification.vendor = Oracle Corporation
    java.specification.version = 1.8

foo is being added to the java.library.path property.

[ed03875]

What we are seeing is that the JVM only looks for library files where the jvm is being loaded from and never searches the LD_LIBRARY_PATH in the example above the jvm would not be able to load libjava.so that resides in the lib directory not the bin directory. We will try 8u322

[ed03875]

Please see below where we are now using 8u322, I fell I am either missing something very basic here (note: the J9 JVM works in this configuration) or the Hotspot JVM does not look anywhere other than the directory where the JVM is loaded from for libraries.

$NOTESBIN/scontroller -jc -s -c Error occurred during initialization of VM Unable to load native library: /home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/jvm/bin/libjava.so: cannot open shared object file: No such file or directory Notice the JVM is not looking in the library path we gave it only looks in bin where we run the JVM from. If we run this using the J9 JVM libjava.so is found using the library path.

$NOTESBIN/jvm/bin/java -version openjdk version "1.8.0_322" OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06) OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)

[karianna]

Interesting... sorry for the extra questions, which flavour version of Linux are you using (I noted the kernel version above) - is it CentOS/Ubuntu/Alpine?

[ed03875]

cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7"

[ed03875]

One thing that may not have been clear is this problem of ignoring the LD_LIBRARY_PATH and -Djava.library.path happens when we load libjvm.so programmatically

[karianna]

I’m on my phone so not reading the full history correctly. I think you gave a sample of how you loaded that programmatically right? If not would love th encode snippet 🙂

On Wed, 9 Feb 2022 at 20:41, ed03875 @.***> wrote:

One thing that may not have been clear is this problem of ignoring the LD_LIBRARY_PATH and -Djava.library.path happens when we load libjvm.so programmatically

— Reply to this email directly, view it on GitHub https://github.com/adoptium/adoptium-support/issues/448#issuecomment-1034172687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABME2GOSUFPMUZBQR3SGV3U2LGN7ANCNFSM5N5UXLQA . You are receiving this because you commented.Message ID: @.***>

-- Cheers, Martijn (Sent from Gmail Mobile)

[ed03875]

We load the JVM in a very standard way res = JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args) This is published in many places.

[jerboaa]

We load the JVM in a very standard way res = JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args) This is published in many places.

That's the source of the problem. The java launcher does that for you. If you do it via JNI you need to handle this yourself. https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#JNI_CreateJavaVM has an example how to do that.

[ed03875]

I wish it was that easy. We believe we are setting the Library path see below. The JVM should be able to find libjava.so in the library path here bin/linux64/bin/jvm/lib/amd64: (note - and D appear on different lines here because of the string length not because of the way we are setting it) notice it does not find the library second bold line

[mkarra@bldlinux10a bin]$ scontroller -jc -s -c options[0]=-Djava.home=/home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/jvm options[1]=-Djava.class.path=/home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin//jvm/lib:/home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/dconsole.jar:.:/home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/ndext/mail.jar options[2]=-Djava.library.path=/home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/jvm/lib:/home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/jvm/lib/amd64:/home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/jvm/bin:/home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/jvm/bin/classic** options[3]=-server options[4]=-Xms16m options[5]=-Xmx256m options[6]=-XshowSettings:properties Error occurred during initialization of VM Unable to load native library: /home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/jvm/bin/libjava.so: cannot open shared object file: No such file or directory

[jerboaa]

The file should be in $JAVA_HOME/jre/lib/amd64/libjava.so for a JDK which if I'm not mistaken isn't in your library path.

[ed03875]

This is the path to our jre directory equivalent /home/mkarra/sandboxes/hotspotjdk/bin/linux64/bin/ this is the jre directory for our product jvm/ this is the the directory where libjava.so resides lib/amd64 So you see the path to libjava.so does exist

[ed03875]

Windows 64 works because all the shared objects are in the bin area With Linux the shared objects are in the lib/amd64 directory for AIX it is similar Hotspot looks one level up from where the jvm is located and looks for libjava.so For us this means HotSpot is ignoring the Library path and is only looking one level up from where the jvm is located for the shared objects. We have tried many things but nothing seems to change the behavior above. This is a huge problem for us and anyone coming from J9 where the library path is used.
It seems this is a similar to bug identified on the Mac oracle bug JDK-7131356. Should I report this as a bug rather than a question ?

[github-actions[bot]]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[karianna]

Bad bot, this needs more thought (I think)

[tomcruise81]

I think I may be running into this as well. Someone much smarter than me might have some thoughts on this - "secure-execution mode"...?

From https://man7.org/linux/man-pages/man8/ld.so.8.html:

LD_LIBRARY_PATH ... This variable is ignored in secure-execution mode.

Is it possible that the JVM itself is:

• running in "secure-execution mode", and thus OS-level calls out to load libraries are also ignoring LD_LIBRARY_PATH
• is explicitly looking at the LD_LIBRARY_PATH environment variable, and is configuring java.library.path based on it and the other default locations that get added
• is solely functioning based off of the paths listed in java.library.path for explicit library loading
• is troubled by libraries that have transitive dependencies as a result of the system calls that it makes

And that transitive dependency loading (which would further rely on ld.so and such) is ignoring LD_LIBRARY_PATH under the covers?

Sorry if this makes NO sense whatsoever.

[tomcruise81]

For additional context, on Windows, if the paths containing my .dll files are added to the PATH environment variable, transitive dependency resolution works fine. However, if those same paths are added to java.library.path, transitive dependency resolution is a no-go. I end up having to fully flesh out the dependency graph and explicitly load libraries in a leaf-to-trunk order to ensure that the JVM has a given library loaded prior to any other libraries that relies on it getting loaded.

[ed03875]

Unfortunately we had to give up on the port of our products to HotSpot. There are to many unresolved issues and the HotSpot port to AIX seems incomplete

[sxa]

Unfortunately we had to give up on the port of our products to HotSpot. There are to many unresolved issues and the HotSpot port to AIX seems incomplete

Temurin does provide a tested JDK8 for AIX - why do you consider it incomplete (This issue was referring to problems you're seeing with LInux/x64 based on the original report)

[github-actions[bot]]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[github-actions[bot]]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[github-actions[bot]]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.