This bug entry actually covers two bugs, but they're closely related and a
simple, combined solution for them is included below.

Both bugs are related to the "export application" feature, and specifically
the shell script which is created automatically in the "application.linux"
export directory. Both have been tested using the example sketchbook,
"examples/Library-OpenGL/Matrix".

The first bug can be found with any exported app that uses OpenGL (or other
external libraries). These apps are exported along with the libraries
"libjogl.so" and "libjogl_cg.so". In order for those libraries to be
loaded correctly, their directory must be added to the LD_LIBRARY_PATH
environment variable. Some Linux configurations have the current working
directory added by default, so there is no problem. For other
configurations, the program will fail to load the OpenGL libraries with the
following error:

Error while running applet.
java.lang.RuntimeException: Before using OpenGL, first select Import
Library > opengl from the Sketch menu.
at processing.core.PApplet.size(PApplet.java:832)
at Matrix.setup(Matrix.java:13)
at processing.core.PApplet.display(PApplet.java:1144)
at processing.core.PGraphics.requestDisplay(PGraphics.java:520)
at processing.core.PApplet.run(PApplet.java:1028)
at java.lang.Thread.run(Unknown Source)


The second bug applies to all exported apps under Linux. When you run the
exported application's startup script, if your current working directory is
the script directory, there is no problem. However, if you try to run the
script when you are located in a different directory, java fails to locate
the app's "lib" directory. This is because, in the startup script, the
classpath is set using relative directory names which no longer apply when
you're not in the base directory.

Here is the Matrix startup script as currently created:

#!/bin/sh
java -cp lib/Matrix.jar:lib/core.jar:lib/opengl.jar:lib/jogl.jar Matrix


To fix it, it could be modified as follows:

#!/bin/sh
APPDIR=`dirname $0`
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$APPDIR
java -cp
$APPDIR/lib/Matrix.jar:$APPDIR/lib/core.jar:$APPDIR/lib/opengl.jar:$APPDIR/lib/jogl.jar
Matrix


The above changes should fix both problems; the LD_LIBRARY_PATH line will
fix the OpenGL problem while the addition of $APPDIR to each classpath
entry will fix the relative directory problem.

cool, thanks for the fix. these are already in the processing shell script
so i dunno why i didn't put it in the export stuff, but i've added for
release 0098. much appreciated.

hello,

with this fix - in the current beta - I still get the import error - this
is easily fixed though with the addition of the vm variable library.path;
the working skript then reads:

#!/bin/sh

APPDIR=`dirname $0`
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$APPDIR
java -Djava.library.path=:$APPDIR -cp
$APPDIR/lib/Matrix.jar:$APPDIR/lib/core.jar:$APPDIR/lib/opengl.jar:$APPDIR/lib/jogl.jar
Matrix

proposed change in addition to making the application script work here
makes setting LD_LIBRARY_PATH obsolete; setting the vm variable is also
what the gui does.

this is with suns j2sdk 1.42_10 on a recent debian sid/unstable system,
which seems to not honor LD_LIBRARY_PATH.

reopened bug - why did it work with other peoples systems?

do you have a modified version of the script that works for you?

edit]
shell script for GL application

attached script lets me start an application exported from processing on linux.
it works from the cwd and from other directories. unlike the currently
distributed script it does not use LD_LIBRARY_PATH because suns jre on this
system does not use that variable, instead it sets the VM argument
java.library.path to that value, like processing itself does. I did not find a
template for this file in the distribution, so cannot provide a replacement.
this is what works for me. thank you, peter.

k great, thanks. i've changed it for the next release, hopefully that won't leave the
LD_LIBRARY_PATH folks out in the cold, though as you say, it shouldn't.

though now that i'm looking at it, i'll bet we need quotes around the strings in cases where
dirname $0 returns something with spaces in the name. can you confirm that quotes would be
needed and/or whether quotes get in the way if placed around the -Dxxxx option and the
contents of the cp param?

edit]
shell script for GL application 2nd ed

this time contains correct quotes to allow spaces in path to application and
application's name itself.

awesome, thanks a ton. i've made the changes. i think i'll still leave it requiring that the sketch
name not have spaces (if you put spaces in the name you're gonna be hosed anyway), but i've
got the quotes in there for the other stuff.

just to double check, this should be used:
-Djava.library.path="$APPDIR"
instead of this:
"-Djava.library.path=$APPDIR"
?

the quotes are to be around strings that may contain spaces, which are not
meant to separate arguments. so yes: quote "$APPDIR" all the time - I just
did quote the whole classpath and not every appearance of APPDIR in there,
which happens to work too, probably because the interpreter keeps spaces
and splits at the colons.

Why not make spaces in sketches possible - if you are at it: quote the
string after the =sign where $PROGRAM gets its value.

I did also change the command substitution from backticks (deprecated) to
$() which is the posixly recommended way to write portable scripts.

right, my only concern was that the path stuff would add quotes into the library.path env var
for java, as java's notoriously bad about doing that sort of thing (see all the frustrated
comments on the board about trying to get the video library installed..)

spaces simply aren't possible for class names, so it's not something we need to support.

at any rate, thanks for the changes, this should be all set for 0104, so i'm closing up again.