https://bugzilla.redhat.com/show_bug.cgi?id=1399793
--- Comment #5 from Roland Grunberg <rgrunber(a)redhat.com> ---
JNR has various ways of locating the shared object libjffi-1.2.so . It is
capable of locating it on the system (java library path) but we don't currently
use this approach. Much like upstream, we package the .so file into a jar file,
jffi-native.jar and JNR must load the jar and locate the .so from there.
JNR will look for libjffi-1.2.so in the "resource" corresponding to the
classloader that loaded com.kenai.jffi.internal.StubLoader (ie.
StubLoader.class.getClassLoader()). Generally this will be the bundle
"com.github.jnr.jffi.native" and of course that contains libjffi-1.2.so.
However, it's also possible that "org.python.pydev.jython" will be
idenitified
as the classloader for the StubLoader because it has a Bundle-ClassPath on
jffi.jar. It doesn't contain jffi-native, so the loading will always fail going
forward.
I would think the only error here is that Eclipse PyDev is missing a symbolic
link to jffi-native in
/usr/lib64/eclipse/droplets/pydev-core/eclipse/plugins/org.python.pydev.jython_5.5.0.201701241700/
.
--
You are receiving this mail because:
You are on the CC list for the bug.