---- Reported by jaeden 2005-08-02 10:28:11 ----
It would be appreciated if you provided a method for auto-loading the lib files
for the native bindings to JOGL. To ease this method, I would recommend renaming
the Solaris libs so that each version has a different file name, allowing them
to be in the same directory. Then, use code similar to this to load the libs in
a static block somewhere. You could optimally make this one function that the
user must call to load them, so as not to load them twice in web start applications.
Here's the code I'm using, that seems to be working:
/** Static initialization - load libraries */
/** Ensure we load GL on startup. This is a replacement for the
* -Djava.library.path=. and -cp .;jogl.jar.
public static void loadOpenGL()
// workaround to allow our loader to do its job
// see http://184.108.40.206/forums/index.php?topic=10262.0;topicseen
// Manually load AWT to work around the problem with error boxes coming
// up claiming it's not found.
// Apparently AWT has to be loaded -before- jogl's .dll files or all
// sorts of errors pop up.
// Now, load the .dll/.so files for the OpenGL C bindings
String strOS = Tools.GetOS(); // wraps System.getProprty("os.name");
// Absolute path to the lib directory
String strJOGL = Tools.Path("lib") + Tools.GetFileSeparator();
// bLoadCg provided for those who aren't using Cg and don't want the
// libs for it loaded
System.load(strJOGL + "jogl.dll");
System.load(strJOGL + "jogl_cg.dll");
if (strOS.startsWith("Mac OS"))
System.load(strJOGL + "libjogl.jnlib");
System.load(strJOGL + "libjogl_cg.jnlib");
System.load(strJOGL + "libjogl.so");
System.load(strJOGL + "libjogl_cg.so");
String strArch = System.getProperty("os.arch");
System.load(strJOGL + "libjogl_solsparc.so");
System.load(strJOGL + "libjogl_solx86.so");
---- Additional Comments From jaeden 2005-08-02 10:28:54 ----
Created an attachment
Proposed implementation of the enhancement
---- Additional Comments From kbr 2006-01-11 00:58:07 ----
JOGL currently offers two deployment strategies neither of which involves any
manual installation of files on the end user's machine. First, JOGL is available
as a Java Web Start extension, which is how all of the jogl-demos are deployed.
Second, with the new JOGLAppletLauncher it is possible to deploy unsigned Java
applets which use JOGL with no manual installation of any files.
I believe these two deployment mechanisms, in conjunction with new support in
Java Web Start in JDK 5 like the Import Facility (see
should be sufficient to cover most deployments of JOGL applications. I do not
think it is a good idea to standardize some directory structure in the JOGL
internals where if a certain API is called with the root of the directory
structure then the code searches through it for the appropriate native library
to load. This is exactly what Java Web Start is designed to abstract away.
I apologize but I'm closing this bug as "will not fix". Please investigate Java
Web Start more thoroughly; I think you will find it surprisingly flexible for
--- Bug imported by email@example.com 2010-03-24 07:47 EDT ---
This bug was previously known as _bug_ 172 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=172
Imported an attachment (id=61)
The original submitter of attachment 61 [details] is unknown.
Reassigning to the person who moved it here: firstname.lastname@example.org.