Bugzilla Bug 173915

Hello,

Following the discussion on the mailing list.
generation-2 does not set LD_LIBRARY_PATH or /etc/ld.so.conf, so linkage with
java libraries do not work with the selected JVM/JDK.

I believe this should be addressed for system integrity, even if you do not
aware of executables that are written this way.

Thanks!

Created an attachment (id=115826) [details]
Makefile

Makefile of test program.

Created an attachment (id=115828) [details]
jni-test.cpp

Test program.

Maybe we could add something based on /etc/java-config-2/current-system-vm/ to
the LDPATH.

(In reply to comment #3)
> Maybe we could add something based on /etc/java-config-2/current-system-vm/ to
> the LDPATH.
> 

yeah

Wouldn't it enforce system settings on user settings?

(In reply to comment #5)
> Wouldn't it enforce system settings on user settings?
> 

Well only one value can go to ld.so.conf and it should be the system setting.
We should just document this use case (I don't think any normal users are doing
what your example is about). Of course we could export LD_LIBRARY path to
prefer user vm over system vm but it would be a new environment variable and
that kind of sucks.

betelgeuse@pena ~ $ env | grep LD
betelgeuse@pena ~ $

Been thinking how to determine the subdirs of
/etc/java-config-2/current-system-vm/ (/lib/i386/ and so on) and I see two
options:

1) java-config installs a superset of all known paths
2) each vm installs its own paths, as part of set_java_env, using the LDPATH
entry in env file, replacing JAVA_HOME with
/etc/java-config-2/current-system-vm/

The 2) seems better because it's not static list that we have to update
manually. There will be some duplication but env-update should uniquize it into
ld.so.conf, no? Or at least ld.so.cache should. There might be a case that
subdir added by another VM is not applicable for current system VM but that
shouldn't hurt, right.

(In reply to comment #6)
> (In reply to comment #5)
> > Wouldn't it enforce system settings on user settings?
> > 
> 
> Well only one value can go to ld.so.conf and it should be the system setting.
> We should just document this use case (I don't think any normal users are doing
> what your example is about). Of course we could export LD_LIBRARY path to
> prefer user vm over system vm but it would be a new environment variable and
> that kind of sucks.

Mmm wonder if gjl launcher should set LD_LIBRARY_PATH to the VM that's
selected.

(In reply to comment #8)
> Mmm wonder if gjl launcher should set LD_LIBRARY_PATH to the VM that's
> selected.
> 

While that would help for our stuff that uses the launcher, it isn't as useful
for user-created scripts and whatnot.

(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Wouldn't it enforce system settings on user settings?
> > > 
> > 
> > Well only one value can go to ld.so.conf and it should be the system setting.
> > We should just document this use case (I don't think any normal users are doing
> > what your example is about). Of course we could export LD_LIBRARY path to
> > prefer user vm over system vm but it would be a new environment variable and
> > that kind of sucks.
> 
> Mmm wonder if gjl launcher should set LD_LIBRARY_PATH to the VM that's
> selected.
> 

currently the gjl laucher does not even respect LD_LIBRARY_PATH when a package
has shared libraries.

why? 

-Djava.library.path trumps LB_LIBRARY_PATH

so an app being called by

LD_LIBRARY_PATH=blah java -Djava.library.path ...
will only see the contents of java.library.path

(In reply to comment #8)
> 
> Mmm wonder if gjl launcher should set LD_LIBRARY_PATH to the VM that's
> selected.
> 

I would think that calling the java binary in /opt would make sure the right
libraries get loaded.

(In reply to comment #9)
> While that would help for our stuff that uses the launcher, it isn't as useful
> for user-created scripts and whatnot.

Is there then any other solution than setting LD_LIBRARY_PATH in say
/etc/profile.d/java-config-2.sh? I'd be for making this at most opt-in since 
this variable is said to be evil :)

(In reply to comment #10)
> currently the gjl laucher does not even respect LD_LIBRARY_PATH when a package
> has shared libraries.

Yeah, probably should append it the same way as we do about env's CLASSPATH.

(In reply to comment #11)
> I would think that calling the java binary in /opt would make sure the right
> libraries get loaded.

Right, so we don't need it in the launcher.

We should check how Fedora or Ubuntu packages behave. I would say that this is
not a case we want to support. If the use knowledgeable enough to know how to
start VM from C/C++ they should be able to set LD_LIBRARY_PATH themselves.
Ebuild installed stuff we can handle with wrappers etc.

I did some research into this matter and the JVM spec does not specify the JNI
library names. This means that you are tied to a specific implementation any
way if you link with something like -ljava. 

http://java.sun.com/docs/books/jni/html/invoke.html

I have the same problem here. However it's when using a python library
(pylucene) that uses jni to call the lucene java API.

I think that java-config should set the correct path to libjava, libjvm, etc.
This can be done on a system wide by setting LDPATH in /etc/env.d/*, and on a
user basis by setting LD_LIBRARY_PATH. I don't see any harm in doing so.

Of course I myself can set LD_LIBRARY_PATH, but then I (and every other jni
user) would need to change it everytime I change my java vm, or when it gets
updated. But this can be done easily by java-config, so why not do it?