Currently os_linux.cpp defines DEFAULT_LIBPATH hard-coded to "/lib:/usr/lib"; with the upcoming multiarch changes in Debian/Ubuntu, libraries will move to multiarch aware locations [1], where these libraries are not found anymore by the class loaders.
In [2], a patch was proposed to have the ClassLoader make the lookup trusting dlopen() instead, and not setting the DEFAULT_LIBPATH. Is there a reason why this is not done in the first place? One thing I could imagine is that dlopen() searches locations like /usr/local/lib too, which it doesn't want. Matthias [1] http://wiki.debian.org/Multiarch [2] https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/737603/comments/7 the proposed patch (without the changes to DEFAULT_LIBPATH): Description: fall back to the built-in system library path If a native library that's been requested can't be found in any of the known paths, fall back to looking it up without a path - i.e., trust dlopen() to do the right thing. This addresses the problem with failing to load libraries when using multiarch. Author: Steve Langasek <steve.langa...@linaro.org> Bug-Ubuntu: https://bugs.launchpad.net/bugs/737603 Index: openjdk/jdk/src/share/classes/java/lang/ClassLoader.java =================================================================== --- openjdk.orig/jdk/src/share/classes/java/lang/ClassLoader.java +++ openjdk/jdk/src/share/classes/java/lang/ClassLoader.java @@ -1676,6 +1676,10 @@ return; } } + File libfile = new File(System.mapLibraryName(name)); + if (loadLibrary0(fromClass, libfile)) { + return; + } } // Oops, it failed throw new UnsatisfiedLinkError("no " + name + " in java.library.path");
