Error in loading jawt

OpenGL Development JOGL Development
#1

Hi all,
I’m currently trying to do a single JAR build for an application that uses JOGL. To allow user to just double click on the JAR file to run it, I need to load the native libraries first, including JOGL’s. I basically based my native libs loader on JOGLAppletLauncher as to how the JOGL native libraries are loaded there.

So in my program I call System.loadLibrary(“jawt”) before I load jogl.dll and jogl_awt.dll.
But afterwards I got stuck in the jawt loading, with the error stack trace as below:

Exception in thread “main” java.lang.UnsatisfiedLinkError: C:\Program Files\Java
\jre1.6.0\bin\jawt.dll: Can’t find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at iro.iro.Test.main(Test.java:7)

Now…Is the only way of solving this is by putting the C:\Program Files\Java\jre1.6.0\bin into system Path?
Because if that is the case, then we need to make sure the users have the proper directory path in their environment variables…quite risky…

If I’m seeing or handling this error in a wrong way, please let me know :stuck_out_tongue:
Thanks in advanced for any suggestion or opinion :slight_smile:

#2

Hi,
You should try java webstart to make an easy deployment… If not you’ll have to deal with the environment variables, and as you said it’s quite risky.
Jnlp takes a little time to get into it but once you have managed it you can have a good user experience with your deployments.

#3

Hi hi,
Actually we already have a java webstart deployment ;D
But we also want to make the application runnable using double-click JAR…until I ran into this problem :stuck_out_tongue:

#4

If you have the Microsoft development tools installed you can run “dumpbin /dependents jawt.dll” to see which native libraries it depends on. For the record, here are the dependents from the current jawt.dll:


  awt.dll
  MSVCR71.DLL
  KERNEL32.DLL

Since you’re already in Java code at that point, MSVCR71.DLL and KERNEL32.DLL are already loaded. The problem must be with awt.dll. You should be able to work around this by calling Toolkit.getDefaultToolkit() before attempting to load jawt.dll.

#5

It works! finally!

speechless
I didn’t realize Toolkit was the solution for it.
knock myself in the head

Thank you so much! :smiley: :smiley: :smiley: :smiley: