Re: Patch: java/lang/natRuntime.cc

[Andrew Haley <aph at redhat dot com>]

Michael Koch writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Am Donnerstag, 21. August 2003 11:47 schrieb Andrew Haley:
 > > Michael Koch writes:
 > >  > -----BEGIN PGP SIGNED MESSAGE-----
 > >  > Hash: SHA1
 > >  >
 > >  > Am Montag, 18. August 2003 14:59 schrieb Andrew Haley:
 > >  > > Michael Koch writes:
 > >  > >  > I wrote a little patch to java/lang/natRuntime.cc to set
 > >  > >  > the property java.library.path like SUNs JDK does it.
 > >  > >  >
 > >  > >  > Please review and comment.
 > >  > >  >
 > >  > >  > Okay for commit ?
 > >  > >  >
 > >  > >  > +
 > >  > >  > +      // Initialize with prefix.
 > >  > >  > +      sb->append (JvNewStringLatin1 (PREFIX "/lib"));
 > >  > >
 > >  > > I don't understand this part.  Why do you do this?
 > >  >
 > >  > Constant string concatenation.
 > >
 > > Look, I understand C perfectly well.  Why do you initialize the
 > > library path with (PREFIX "/lib") ?
 > 
 > Well, it adds the path where libgcj was install to the 
 > java.library.path property. This directory is normally the directory 
 > where additional native libraries should be searched and loaded from 
 > like the AWT peer libs and others.

This is wrong.  If we set java.library.path, we should set it to what
the path actually is, not what we think it ought to be.

On GNU/Linux, this is how the path is computed:

  If there is no DT_RUNPATH dynamic section attribute in the binary,
  try the DT_RPATH attribute.

  Then try LD_LIBRARY_PATH.

  If there is a DT_RUNPATH, try that.

  Look in /etc/ld.so.cache.

  Unless the binary was linked with -z nodeflib, try /lib, and then
  /usr/lib,

This is rather hard.  It would probably suffice simply to set
java.library.path to LD_LIBRARY_PATH, although this will be somewhat
misleading if the binary has been linked with -rpath.  But simply
prefixing the libgcj install directory is wrong.

Andrew.