JNI, System Shared Library Path and LD_LIBRARY_PATH

[David Hageman]

I have run into an issue that is just driving me crazy. At my day job,
I have a user who is working with Java Web Start. It is an interesting
technology and almost makes working with java very easy.

The problem is that he is incorporating a JNI library called jogl into
his application. What this means is that C system libraries are being
accessed via the java software via a "glue" interface. So much for that
write once, run anywhere stuff eh?

At any rate, I am having issues where the system "native" libraries
can't be found.

I have found a solution, but I don't understand why it works when my
other attempts failed.

The solution is to set an environment variable LD_LIBRARY_PATH to the
location of the "native" libraries that the java application will
attempt to find. If you set this environment variable - it runs just fine.

Looking for a system wide solution - I added the location of the
"native" libraries to the global dynamic library search path. I have
verified that the system can find them by doing a ldconfig -v and
grepping for the libraries in question. However - this doesn't work.
The application fails to find the libraries with this method.

My question is this: Why does the LD_LIBRARY_PATH solution work over
the more generally agreed upon better solution (adding the libraries to
the global search path)?

--
========================================================
D. Hageman <dhag...@dracken.com>
Dracken Technology, Inc. http://www.dracken.com/
========================================================

[Jeffrey Watts]

Shooting from the hip, my guess would be that the Java VM doesn't look at the system library path because it's trying to be system agnostic.  So the jogl library won't be able to see the path.

However, given that environment variables seem to be something that's present on most (all?) operating systems, perhaps the VM does look at those.  That might explain the behavior you're seeing.

Jeffrey.

On Mon, Oct 12, 2009 at 10:32 AM, David Hageman <dhag...@dracken.com> wrote:

I have run into an issue that is just driving me crazy.  At my day job,
I have a user who is working with Java Web Start.  It is an interesting
technology and almost makes working with java very easy.

The problem is that he is incorporating a JNI library called jogl into
his application.  What this means is that C system libraries are being
accessed via the java software via a "glue" interface.  So much for that
write once, run anywhere stuff eh?

At any rate, I am having issues where the system "native" libraries
can't be found.

I have found a solution, but I don't understand why it works when my
other attempts failed.

The solution is to set an environment variable LD_LIBRARY_PATH to the
location of the "native" libraries that the java application will
attempt to find. If you set this environment variable - it runs just fine.

Looking for a system wide solution - I added the location of the
"native" libraries to the global dynamic library search path.  I have
verified that the system can find them by doing a ldconfig -v and
grepping for the libraries in question. However - this doesn't work.
The application fails to find the libraries with this method.

My question is this:  Why does the LD_LIBRARY_PATH solution work over
the more generally agreed upon better solution (adding the libraries to
the global search path)?

--

"He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself." -- Thomas Paine

[John Heryer]

Yep - It's where the jvm looks to find the libraries.

--
--
John Heryer

[David Hageman]

It appears that you guys are correct. I didn't want to believe it to be
the case, but I wrote a couple of test applications to verify a few things.

It appears that they munge the java.library.path property on startup to
just include the library path for the jvm related .so files and the main
system library paths (e.g. /usr/lib). Everything else is thrown away.

The only way to dynamically modify this path is to set LD_LIBRARY_PATH
or pass it -Djava.library.path= on the command line.

Debian takes a more brute force option by hard coding additional library
paths into their JNI libraries. That way they can live in the
/usr/lib/jni and /usr/lib/jni64.

A quick fix is to move or symlink my JNI libraries to /usr/lib. This
may be the route I go. I have too many users who don't understand
environment variables or that they shouldn't remove the lines in their
bash rc files regarding the global bash config.

Thanks for pushing me in the right direction. *sigh*

--

[Adrian Griffis]

On Mon, Oct 12, 2009 at 1:58 PM, David Hageman <dhag...@dracken.com> wrote:
> A quick fix is to move or symlink my JNI libraries to /usr/lib.  This
> may be the route I go.

I occasionally do similar things on my systems. I do recommend using
a symlink instead of moving the libraries into /usr/lib. There may
come a time when you want to know which things came with the OS and
which you added. symlinks do a nice job of telling you where things
come from.

Adrian

[David Hageman]

Adrian,

You are absolutely right - great advice. I go one step further ... I
try to bundle all my 3rd party software into RPMs. It makes managing
the 75+ systems under my control much much easier.

--

[Aaron Brown]

David Hageman wrote:
> A quick fix is to move or symlink my JNI libraries to /usr/lib. This
> may be the route I go. I have too many users who don't understand
> environment variables or that they shouldn't remove the lines in their
> bash rc files regarding the global bash config.

One other solution (not necessarily "best", but "other"):

Let's say "which java" says java is at /usr/bin/java. You could create
a shell script at /usr/local/bin/, call it "java", and point JAVA_HOME
at the script. With the script, you would have the power to
prepend/append extra -D arguments to the user's command, then execute
/usr/bin/java with the customized args.

- Aaron

--
Aaron Brown :: aa...@thebrownproject.com :: www.thebrownproject.com

[Steve Nordquist]

JNI libraries can be a little less pure, so to prevent borked Java
stacks and/or crossing systime() read threads, or for system-agnostic
behavior as Watts said, Sun cut you off their path by default. It
also keeps library paths privately hashed until the app needs to have
a discoverable one. So if you set 2 global variables, you can pass a
path. Debian's plum called it and said it's 2004 Java, and if it
compiled it is cluster-safe as given.

[Austin Morgan]

Aliases might be a cleaner method of doing that. I didn't read the beginning
of the thread, but you can alias java and prepend additional options, you
can even create a custom command so you can call java with normal settings
and java with your custom arguments.

----------------original message-----------------
From: "Aaron Brown" aa...@thebrownproject.com
To: kul...@googlegroups.com
Date: Mon, 12 Oct 2009 14:49:55 -0500
-------------------------------------------------