Library conflict - Loading the same library "twice" using different versions

1,339 views
Skip to first unread message

Erik Nijkamp

unread,
May 4, 2012, 8:47:55 AM5/4/12
to jna-...@googlegroups.com
Hey guys,

I'm trying to load a specific version (2.4.2) of the freetype library.

It seems like the open-jdk-7 already ships with its own version of freetype (2.4.8) which is loaded in the current process.

So if I invoke

Native.loadLibrary(libName, FT2Library.class)

where libName is an absolute path pointing to my freetype version, freetype still spits out "2.4.8". The exact same code works fine with open-jdk-6, so I'm quite sure that jna uses the "in-process" symbols rather than dynamically linking to my .so file.

Is there a way to specifically load and link to an external .so file, if there's another version of that .so already loaded?

Thanks so much!
 - Erik

Timothy Wall

unread,
May 4, 2012, 9:22:17 PM5/4/12
to jna-...@googlegroups.com
It's quite possible that the library is opened with RTLD_GLOBAL by the JVM (and JNA opens it that way), which means the symbols from the two libraries will overlap.

If you open the new library without that flag, you should be able to get the right version (panga has filed an issue and a workaround -- https://github.com/twall/jna/issues/44). In this case, you may need to "reopen" the old version to get it to *not* have RTLD_GLOBAL set, but the workaround may be sufficient. This starts getting into some system-specific dlopen arcanery, so YMMV, but at least two people have had success using the workaround addressing two different issues.

Erik Nijkamp

unread,
May 5, 2012, 11:39:18 AM5/5/12
to jna-...@googlegroups.com
Thanks for the reply.

I stumbled over with workaround a while ago. Unfortunately, (re-)opening both the .so used by the JVM and my specific .so with RTLD_LAZY doesnt do the trick.

I don't think that this can work once one of the libraries is already loaded. And without having access to the JVMs .so handle I cannot close the .so beforehand.

Any other ideas how to tackle this?

Thanks!
 -- erik

Timothy Wall

unread,
May 5, 2012, 6:58:41 PM5/5/12
to jna-...@googlegroups.com
You can get the handle to the JVM's version by doing a dlopen on it; alternatively, can you simply put *your* version into the library path prior to the other one at the time of VM launch?

Erik Nijkamp

unread,
May 8, 2012, 8:07:46 AM5/8/12
to jna-...@googlegroups.com
Thanks for the reply.

I renamed all freetype (FT2_ prefix) symbols with a prefix of my own. Still didn't to the trick.

I tried to:

Pointer handle = dl.dlopen("/usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0", dl.RTLD_GLOBAL);
dl.dlclose(handle);

which causes the JVM to crash and the core dump contains no useful hints.

I don't want to alter the library paths prior to JVM launch ... any other ideas?

Thanks so much Timothy!
-- erik

Erik Nijkamp

unread,
May 8, 2012, 2:15:05 PM5/8/12
to jna-...@googlegroups.com
Never mind, I've overseen some unexpected symbols. Symbol rewriting did the job.

Timothy Wall

unread,
May 8, 2012, 6:25:06 PM5/8/12
to jna-...@googlegroups.com

On May 8, 2012, at 8:07 AM, Erik Nijkamp wrote:

> Thanks for the reply.
>
> I renamed all freetype (FT2_ prefix) symbols with a prefix of my own. Still didn't to the trick.
>
> I tried to:
>
> Pointer handle = dl.dlopen("/usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0", dl.RTLD_GLOBAL);
> dl.dlclose(handle);
>
> which causes the JVM to crash and the core dump contains no useful hints.

I think you would want to open with RTLD_LOCAL; RTLD_GLOBAL is the default for JNA (and some systems).
Reply all
Reply to author
Forward
0 new messages