Skip to Main Content

Java HotSpot Virtual Machine

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Loading a native library that loads the libraries itself

843829Jul 18 2007 — edited Jun 12 2010
I'm trying to wrap libpurple (http://developer.pidgin.im/wiki/WhatIsLibpurple) for use in Java code. Everything is done in the linux and freebsd boxes (with the same problems). The problem is libpurple itself has an initialization procedure (just a function to call) where it loads some "plugin" libraries additionally.
This initialization (and loading sub-libraries) works well in the native application example, but produces an error when using it via JNI. So I do the following:
System.load("aSimpleLibpurpleWrapper.so");
NativeInterfaceClass.initLibpuple(); //(actually calls native libpurple initialization described above)
Then I get an errors in SDTERR from JVM:
/libexec/ld-elf.so.1: /usr/local/lib/purple-2/perl.so: Undefined symbol "purple_plugin_register"

Here's deps. listing:

$ ldd ./aSimpleLibpurpleWrapper.so
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x4816f000)
libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x48178000)
libxml.so.5 => /usr/local/lib/libxml.so.5 (0x48205000)
libpurple.so.0 => /usr/local/lib/libpurple.so.0 (0x4826d000)
libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x4830e000)
libdbus-glib-1.so.2 => /usr/local/lib/libdbus-glib-1.so.2 (0x48343000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x4835c000)
libicui18n.so.36 => /usr/local/lib/libicui18n.so.36 (0x4844f000)
libz.so.3 => /lib/libz.so.3 (0x48575000)
libc.so.6 => /lib/libc.so.6 (0x48086000)
libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x48586000)
libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x485bb000)
libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x485bf000)
libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x485c3000)
libm.so.4 => /lib/libm.so.4 (0x486d1000)
libicuuc.so.36 => /usr/local/lib/libicuuc.so.36 (0x486e7000)
libicudata.so.36 => /usr/local/lib/libicudata.so.36 (0x487ef000)
libpthread.so.2 => /lib/libpthread.so.2 (0x4919f000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x491c4000)

$ ldd /usr/local/lib/purple-2/perl.so
libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x48175000)
libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x481aa000)
libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x481ae000)
libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x481b2000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x4823f000)
libperl.so => /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so (0x48332000)
libm.so.4 => /lib/libm.so.4 (0x4843f000)
libcrypt.so.3 => /lib/libcrypt.so.3 (0x48455000)
libutil.so.5 => /lib/libutil.so.5 (0x4846d000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x48479000)
libicui18n.so.36 => /usr/local/lib/libicui18n.so.36 (0x48482000)
libicuuc.so.36 => /usr/local/lib/libicuuc.so.36 (0x485a8000)
libicudata.so.36 => /usr/local/lib/libicudata.so.36 (0x486b0000)
libpthread.so.2 => /lib/libpthread.so.2 (0x49060000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x49085000)

So you see the "plugin" that can't be linked really misses the main library dependency, but aSimpleLibpurpleWrapper.so it works well in the native apps 'cause libpurple is already loaded (as its code loads that plugin), so everything works as expected, but not with JVM for some reason.

Plz, say what I miss there
Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Jul 10 2010
Added on Jul 18 2007
4 comments
363 views