RE: [Plplot-devel] How can java be told permanently about where to find libplplot(d)?

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > On Mon, 12 Nov 2001, Geoffrey Furnish wrote:
 > 
 > > The jvm has already been linked by the time we get it, there isn't
 > > much we can do about it.  When you dlopen something in the jvm, it's
 > > gonna look wherever it looks.  You can influence this by
 > > LD_LIBARY_PATH, or by editng ld.so.conf or whatever.  That's to /find/
 > > libplplot.so.
 > 
 > Yes, that is the crux of the issue.  I am interested in non-LD_LIBRARY_PATH
 > options (if they exist) for solving this problem under java.
 > 
 > >
 > > ....In other words, I think you are expressing a beef with the JVM, not
 > > with plplot.  If I've misunderstood, please clarify.
 > 
 > I agree there is nothing we can do with libplplot.  What I am asking is
 > whether there is a mechanism *under java* (some additional command in
 > PLStream.java or some javac option) which allows java to find libplplot (or
 > any other C extension library) when it is installed in a non-standard place.
 > I would be surprised and disappointed if java relied solely on
 > LD_LIBRARY_PATH to solve this problem.

Well, it's not anything special to java.  We're just talking about the
semantics of dlopen(), which all programs use to load .so's.  At the
top of man dlopen, I find:

       dlopen loads a dynamic library from the file named by  the
       null  terminated  string  filename  and  returns an opaque
       "handle" for the dynamic library.  If filename is  not  an
       absolute  path  (i.e., it does not begin with a "/"), then
       the file is searched for in the following locations:

              A colon-separated list of directories in the user's
              LD_LIBRARY path environment variable.

              The     list     of    libraries    specified    in
              /etc/ld.so.cache.

              /usr/lib, followed by /lib.

I take this to mean you /can/ give it an absolute path.  Although I
have never actually tried that myself.  So, I guess it would be
possible for PLplot's install target to sed the plconfig.java file so
that it traded loadLibrary( "plplot" ); for something totally specific
like System.loadLibrary( "$prefix/lib/libplplot.so" );.  Maybe that
would work.

Note, however, that the java user will still have to add
$prefix/lib/java to CLASSPATH.  But if that much is done, then perhaps
the plconfig that is loaded there, would be able to find libplplot.so
using the full path spec sed'd in at install time.

If you wanted to try this out, note that you could just edit
plconfig.java by hand after installation, just to see.  But remember
to recompile plconfig.java afterwards.  If this approach does work,
we'd have to think a bit to figure out exactly how to feed this
approach into an improved install target.  We wouldn't want to sed the
plconfig.java in the tmp dir.  So we'd have to set up a separate build
tree for all the java stuff, sed that, then compile it, then copy it
all into place (or use a .jar file).