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 attachment 115826 [details] Makefile Makefile of test program.
Created attachment 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?
I would need java-config's sources to make this change happen.
