[rfc] Let the classloader search for system libraries, don't hard-code DEFAULT_LIBPATH

[Matthias Klose]

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.langasek at 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");