Return of the "java.lang.UnsatisfiedLinkError: Can't load library: /System/Library/Frameworks/gluegen-rt.Framework/gluegen-rt" exception...

Hi,

I have a project that uses JOGL2, and which follows all the guidelines for correctly loading the native libraries (jars inside the plugin, use of FileLocator to tell the JarUtil.Resolver where to look, removal of old j3D libraries from the system paths, and so on).  I ran it happily on a combination of MacOS X Yosemite, Eclipse Juno 3.8.2, and JDK 6 to 8.

Recently, we moved the project to Eclipse Luna (4.3.2) and the good old exception "java.lang.UnsatisfiedLinkError: Can't load library: /System/Library/Frameworks/gluegen-rt.Framework/gluegen-rt" appeared, first on one computer, and then on others. It seems a little bit random, and sometimes a restart of the computer removes it).

Luna is the only difference found between the two installations. However, this change in Eclipse version could also signify a change (in some configurations) of the default JDK used to run Eclipse (and, then, to run RCP projects launched from Eclipse).

Could this be the culprit ? Juno ran by default on JDK 6 (the one by Apple), while Luna seems to launch on the latest installed (JDK 7 or 8, the ones by Oracle). And, in that case, I remember having read somewhere that the format (or at least the extension) of dynamic libraries used by the JDK on MacOS X had changed (from "jnilib" to "dylib", is that it ?). Should I rename the libraries inside the macos-x-universal jars to accommodate for this ? And in that case, what would happen for people still running on JDK 6 (some of our users won't/cant upgrade) once we release the application ?

Thanks in advance for some advices. In the meanwhile, I will experiment some combinations of library names/OS version/JDK version — but if you already have faced (and solved) the problem, that would be a great help !

Cheers
Alexis

Alexis Drogoul wrote

Recently, we moved the project to Eclipse Luna (4.3.2) and the good old exception "java.lang.UnsatisfiedLinkError: Can't load library: /System/Library/Frameworks/gluegen-rt.Framework/gluegen-rt"

One known reason to get this exception is if some application installer has decided to place JOGL jars (gluegen-rt.jar, jogl-all.jar ) in the /System/Library/Java/Extensions folder

JogAmp strongly recommend to never put any jars inside the java ext or extension folders.
If you find JOGL jars in the Extension folder, remove them.

Hi,

Thank you for your answer. Actually, this had also been verified. And the only difference between "when it worked" and "when it failed" is the transition from Eclipse Juno to Eclipse Luna. The same code, the same OS, the same installed libraries… So I suspect that the "default" use of JDK 7 or 8 by Luna (compared to the default use of JDK 6 by Juno) is the cause (or one of the causes).

Cheers
Alexis

Apple shipped Java3D 1.3 with JOGL 1 (and GlueGen) within Mac OS X for years, they are installed as extensions, typically in the kind of directory you talked about. We have made some efforts especially in JOGL 2.3.1 to avoid name clashes so that when the JVM picks the JARs of JOGL 2, it picks the right native libraries too but you can still get an UnsatisfiedLinkError if it picks the JARs of JOGL 2 but it picks the native libraries of JOGL 1. In my humble opinion, both GlueGen, JOGL and Java3D should be uninstalled. I remind you that the extension mechanism has been removed from Java 1.9, nobody should rely on it.

JogAmp tests all builds of JOGL on MacOSX 10.9.5 using both JDK6 and JDK 8

Platform: MACOS / Mac OS X 10.9.5 (10.9.5), x86_64 (X86_64, GENERIC_ABI), 2 cores, littleEndian true
Platform: Java Version: 1.8.0_20 (1.8.0u20), VM: Java HotSpot(TM) 64-Bit Server VM, Runtime: Java(TM) SE Runtime Environment
https://jogamp.org/chuck/job/jogl/label=macosx-10_7-x86_64-nvidia_jre7/lastCompletedBuild/testReport/

Platform: MACOS / Mac OS X 10.9.5 (10.9.5), x86_64 (X86_64, GENERIC_ABI), 2 cores, littleEndian true
Platform: Java Version: 1.6.0_65 (1.6.0u65), VM: Java HotSpot(TM) 64-Bit Server VM, Runtime: Java(TM) SE Runtime Environment
https://jogamp.org/chuck/job/jogl/label=macosx-10_6-x86_64-nvidia/lastCompletedBuild/testReport/

JDK 6, 7 and 8 is known to work on MacOSX
Try run JogAmp from the command line outside of eclipse to check that your JDK installation is ok.
You can run a runtime check by unpacking the 2.3.1 jogamp-all-platforms.7z
cd jogamp-all-platforms
sh ./etc/test.sh

Hi,

Thanks for your answers and pointers.

No problem to run the tests under MacOS X 10.10.2 and JDK 1.8 (this is one of the configurations that failed on Eclipse Luna) — jogl is up and running and the jars are picked in the right directory (the "jar" directory within the jogamp-all-platforms folder).

All the directories listed for the soon-to-be-abandoned extensions mechanism by the JDK

(namely : /Users/YOUR_NAME/Library/Java/Extensions
/Library/Java/JavaVirtualMachines/YOUR_JDK/Contents/Home/jre/lib/ext
/Library/Java/Extensions
/Network/Library/Java/Extensions
/System/Library/Java/Extensions
/usr/lib/java)

have also been cleansed from anything related to j3D, gluegen and jogl (easy: there was nothing as I had already emptied these extensions before).

Now, under the same configuration, things happen randomly : sometimes it works, sometimes it doesn't. The same with a colleague of mine who runs under 10.9.5. Could the "Resolver" we set the first time a JOGL view is opened be rewritten somewhere with a default value ? (I dont think so as this possibility is tested in JarUtil, but who knows ? Reflection can make miracles :)).

I'm a bit lost, actually. Will continue digging, of course, but I dont know exactly in which direction !

Alexis

Alexis Drogoul wrote

Hi,

Thanks for your answers and pointers.

No problem to run the tests under MacOS X 10.10.2 and JDK 1.8 (this is one of the configurations that failed on Eclipse Luna) — jogl is up and running and the jars are picked in the right directory (the "jar" directory within the jogamp-all-platforms folder).

Good!

Alexis Drogoul wrote

Now, under the same configuration, things happen randomly : sometimes it works, sometimes it doesn't.
...

I'm a bit lost, actually. Will continue digging, of course, but I dont know exactly in which direction !

Alexis

Try explain to us how you setup this "configuration" that makes things misbehave using Eclipse Luna.
Does the exception happen only after you export your application using eclipse?

Remember that eclipse has its own classloader that is used to load jar's from inside jars something java normally do not support.
If you use eclipse to export an application as a Java.Runnable_JAR_file then remember that only the following two library handling options work:
Library handling:
           Copy required libraries into a sub-folder next to the generated JAR
Library handling:
           Package required libraries into generated JAR
https://jogamp.org/wiki/index.php/JogAmp_JAR_File_Handling#Eclipse

When you run your application then you may want to enable logging of how JOGL uses gluegen to load the native librarys. This can be done by passing -Djogamp.debug.NativeLibrary to java.

In my humble opinion, there are still some obsolete libraries somewhere, use the flag Xerxes mentioned to see where it finds them.

Alexis Drogoul wrote

Now, under the same configuration, things happen randomly : sometimes it works, sometimes it doesn't. The same with a colleague of mine who runs under 10.9.5. Could the "Resolver" we set the first time a JOGL view is opened be rewritten somewhere with a default value ? (I dont think so as this possibility is tested in JarUtil, but who knows ? Reflection can make miracles :)).

Hi Alexis,

I'm the one who put in the Resolver, to allow RCP apps to run correctly with JOGL 2 :) It works for me for Eclipse Luna on Windows at least, I'm not sure if I've tried Luna on OS X. But one thing you can do to test it is set a breakpoint inside your resolve() function that you provide, and look at the URLs that are fed into it -- this may give you some hint of what Eclipse is doing different between Luna and previous versions.

Hi Wade,

Thanks for your answer. It gave me an idea and I asked my colleague (who had the error, but lives 11000 kms away) to print out the input and output URLs. I took the time to compare them to my inputs and outputs (the error had not manifested itself since yesterday on my computer).

The input, of course, was the same. Regarding the first output, I spotted one tiny difference (besides the user name and the location of the workspace).

On mine: jar:file:/Users/XXXXXXX/Downloads/eclipse/../../GAMA/LocalGIT/ummisco.gama.opengl/gluegen-rt.jar!/com/jogamp/common/os/Platform.class

On his: jar:file:/Users/XXXXXXX/Downloads/Eclipse Luna/../../GAMA/LocalGIT/ummisco.gama.opengl/gluegen-rt.jar!/com/jogamp/common/os/Platform.class

Notice the difference ? His installation of Eclipse Luna is in a folder called "Eclipse Luna" (*with* a space), mine is in "eclipse" (*no* space).

I immediately added a space to my folder name and bam ! I was able to reproduce the problem. Removed the space, the problem went away (i.e. no more exception).

So I guess there is a bug, either in JarUtil or in Eclipse Luna, that prevents JOGL from correctly handling URLs with a space in them. Can you confirm this ?

To be clear, this bug is reproducible on our two machines, but I'm not entirely convinced it is the only cause (as I never added a space before to my folder names and had the exception on a more or less random basis). I will try to understand what other problem can explain this erratic behavior (although it is more complicated now that it  seems to work flawlessly…).

In any case thanks to all of you for your very helpful comments !

Cheers
Alexis

Alexis Drogoul wrote

Notice the difference ? His installation of Eclipse Luna is in a folder called "Eclipse Luna" (*with* a space), mine is in "eclipse" (*no* space).

Ah, now I remember this. I ran into this at some point, but forgot about it :) Turns out, there's an error in Eclipse's FileLocator.resolve() where it doesn't escape spaces properly (the bug report is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=145096). Apparently a lot of Eclipse legacy code depends on this wrong behavior, so it doesn't sound like they're going to fix it.

A fix we can do on our side is to change the resolver you create in your code to escape the spaces properly. Apparently if you change the resolved URL to a URI using the 3-argument constructor, then back to an URL, it'll escape it for you, like so:

JarUtil.setResolver( new JarUtil.Resolver() {
    public URL resolve( URL url ) {
        try {
            URL urlUnresolved = FileLocator.resolve( url );
            URL urlResolved = new URI( urlUnresolved.getProtocol(), urlUnresolved.getPath(), null ).toURL();
            return( urlResolved );
        }
        catch( IOException ioexception ) {
            return( url );
        }
        catch( URISyntaxException urisyntaxexception ) {
            return( url );
        }
    }
} );

I haven't tested this fully, but I think this is how I did it. Not sure why this isn't in my current code base, I must have done it in a branch somewhere and forgotten it.

Hi Wade,

Thanks ! That's exactly how I wanted to fix this, although I was waiting for some kind of confirmation… And you gave it ! Do you think that this behavior could somehow be pushed in JarUtil (i.e. encoding the URL obtained from the resolver — shouldn't be too harmful for already encoded URLs) ? In the meantime, I'll push it to my own codebase…

Thanks again,

Cheers
Alexis

Shouldn't we put this thing into our own code base?

On 06/03/2015 03:24 AM, Wade Walker [via jogamp] wrote: Maybe we can use our com.jogamp.common.net.Uri impl. instead of URI,
since Uri implements RFC 2396 _and_ RFC 3986 (multibyte unicode character
encoding).

~Sven

On 06/03/2015 10:53 AM, Sven Gothel wrote:
>
> Maybe we can use our com.jogamp.common.net.Uri impl. instead of URI,
> since Uri implements RFC 2396 _and_ RFC 3986 (multibyte unicode character
> encoding).

<http://jogamp.org/deployment/jogamp-next/javadoc/gluegen/javadoc/com/jogamp/common/net/Uri.html>

<https://tools.ietf.org/html/rfc3986#section-2.1>

<https://tools.ietf.org/html/rfc3986#section-2.1>


~Sven

gouessej wrote

Shouldn't we put this thing into our own code base?

I had thought about submitting a patch for this, but I wasn't sure what to think about working around an Eclipse bug inside JOGL. It's only one extra line in the user's URL resolver, so not the end of the world. I just need to document it better :)

On 06/03/2015 10:49 PM, Wade Walker [via jogamp] wrote:
>     gouessej wrote
>     Shouldn't we put this thing into our own code base?
>
> I had thought about submitting a patch for this, but I wasn't sure what to
> think about working around an Eclipse bug inside JOGL. It's only one extra
> line in the user's URL resolver, so not the end of the world. I just need to
> document it better :)

Mind that URL [re-]creation costs one DNS lookup.

~Sven

On 06/04/2015 12:42 PM, Sven Gothel wrote:
-  interface JarUtil.Resolver {
-     URL resolve( URL url ) {

+  interface JarUtil.Resolver {
+     Uri resolve( Uri uri ) {

JarUtil.Resolver.resolve(..) is being called
in a method which already transform the URL to Uri,
hence we could rely solely on Uri w/o DNS lookup
while still supporting UTF-8 character escaping.

~Sven

On 06/04/2015 12:48 PM, Sven Gothel wrote: BTW .. this earlier transformation would also fix the
Eclipse issue, since:
  URI uri = Uri.valueOf(url);
will escape the path properly.

~Sven

Thank you guys! I was facing the same problem this morning and this post quickly resolved it! :)