[rfc] Let the classloader search for system libraries, don't hard-code DEFAULT_LIBPATH
steve.langasek at ubuntu.com
Thu Mar 24 09:10:15 PDT 2011
On Thu, Mar 24, 2011 at 02:09:17PM +0000, Alan Bateman wrote:
> Matthias Klose wrote:
> >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 , where these libraries are not found anymore by
> >the class loaders.
> So is the issue that java.library.path isn't going to be set
> correctly when libraries are migrated to this new layout? Just
> wondering if the setup of the search path (in
> os::init_system_properties_values would be better place to do
> consider this). A concern with changing System.loadLibrary is that
> it has a wider impact.
Well, from my side the concern is that the system library path (as seen by
ld.so) can be changed at runtime on Linux via /etc/ld.so.conf, and I think
it's bad for Java to have a different, hard-coded-at-build-time view of the
system path that may differ.
I understand the concern about this leaving java.library.path incomplete,
and was wondering about this myself when proposing the preceding patch (but
didn't know the answer, not being familiar with Java language conventions
myself). If it's important to maintain the full search path in
java.library.path rather than falling back to the system path, then
Matthias's follow-up patch seems to be the way to go.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek at ubuntu.com vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 828 bytes
Desc: Digital signature
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110324/46fce79d/attachment.bin
More information about the distro-pkg-dev