Colin Walters wrote: > On Thu, May 22, 2008 at 5:33 PM, Felix Schwarz > <felix.schwarz@xxxxxxxxxxxxxx> wrote: > >> c) How to get the correct vm type? On i386 there is a client and a server >> vm. Is there a way I can "just" get the client vm directory (and as a >> fallback the server vm)? > > Hm, if the project needs to poke at the internal VM libraries I'm not > sure there's a clean way to do that, but an OpenJDK hacker might be > able to give you an answer. This is a bit mysterious. I guess I don't understand why PyLucene would want to poke at the internal VM libraries. >> d) JCC uses JNI so the library paths must be set correctly at runtime. >> Unfortunately, the OpenJDK package does not add its paths to >> /etc/ld.so.conf.d (did I miss something?) Is there another workaround >> besides using rpath (bad, see a) or filing a bug against OpenJDK? OpenJDK doesn't need to add its paths to /etc/ld.so.conf.d. It calls (for example) putenv("LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:\ /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:\ /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64" + the old path.) and re-execs java. > Right now, you should hardcode the paths to the library in your package. See: > http://fedoraproject.org/wiki/Packaging/Java#head-61a3ee0d05ff616ef9be2021b489610e036fd932 > Specifically, "If the JNI-using code calls System.loadLibrary you'll > have to patch it to use System.load, passing it the full path to the > dynamic shared object." > > For an example of this see > http://cvs.fedoraproject.org/viewcvs/devel/javasqlite/ > > This is necessary until we get multilib-awareness into OpenJDK upstream. Interesting. What multilib-awareness do you think we need? It's not immediately clear to me where the beinefit would be. Andrew. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list