Unsatisified link error when using jogl 1.1 rc and webstart

OpenGL Development JOGL Development
#1

I’m trying to use the latest build of jogl 1.1.0-rc.1 with webstart, and I keep getting the following error:
Exception in thread “AWT-EventQueue-2” java.lang.UnsatisfiedLinkError: no gluegen-rt in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at com.sun.gluegen.runtime.NativeLibLoader$1.run(NativeLibLoader.java:68)

My .jnlp file references a jogl.jnlp file which looks like the following:

<?xml version="1.0" encoding="utf-8"?> JOGL Sun Microsystems, Inc. JOGL Java programming language binding for the OpenGL 3D graphics API.

Can anybody see what I’m doing wrong. It worked with the September release of jogl, but ever since the gluegen-rt.jar has been included I get the error.

#2

Did you make sure that your java.library.path points to a directory that contains the libgluegen-rt.so?

Edit: of course I totally missed the webstart part so you can ignore me :wink:

#3

OK I found out that I now need the gluegen-ft.jnlp and its set of jars. So I went to http://gluegen.dev.java.net/ and downloaded the webstart.zip packages and set that up.

Now when I launch my application I don’t get the message but nothing happens when the screen should initialise, and the java console freezes also (no output, redraw etc).

Any ideas.

#4

gluegen-rt.jar is not a nativelib jar file, it’s a normal one and should be referenced with a tag, not a one.

Could you try just pointing at our jogl.jnlp file at http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp and see whether that works?

If it doesn’t, could you run the jstack tool from the command line (passing it the PID of the hung javaw / javaws process) and post the thread dump?

#5

I replaced the reference to my jogl with http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp and the same thing happens. The GLJPanel hangs. I encode the jstack output for the javaws process.

#6

What graphics card do you have? Are you running your vendor’s latest drivers? If not, could you please upgrade them and see whether that resolves the problem?

Your app is locking up in native code during a call to glXQueryDrawable, which should not happen assuming proper synchronization between JOGL and the AWT. I would first recommend you try upgrading your drivers, and if that doesn’t solve the problem then try using a GLCanvas instead of a GLJPanel. Is there a particular reason in your app why you need to use the lightweight component?

Do you know when this behavior started occurring? Was it due to a JOGL upgrade or were there other software upgrades involved? Have you tried running on other machines? There were a lot of bug fixes between JSR-231 1.0.0 and 1.1.0-rc1, but I don’t think there were any substantial changes in this area that could have impacted correctness.

#7

I’m running Fedora Core 5 with nvidia driver 8776 and kernel-2.6.18-1.2257.fc5 on a Pentium 2.4 GHz machine with a GeForce 6200. I can’t get to upgrade at this moment because the machine is serving up stuff for some other processes right now.

My application is embedded in a Swing framework of overlapping windows with various level of transparency thus I need the GLJPanel. My application works with the September release of jogl which didn’t have the gluegen-rt stuff, and I haven’t installed any other software recently.

The only thing I’ve noticed is that when I try to enable the opengl-pipeline stuff via in the .jnlp file, I get a core dump when the application starts. I’ve meant to try and track this down but I was busy getting my app to work.

I’ll try and upgrade later and post the results.

#8

OK. I installed the latest nvidia driver and it solved the immediate problem. However I still get a core dump when I try to enable the opengl java2D pipeline. I’ll try figure that out another time.

Thanks!