Tinkering with Nasa's WorldWind on Fedora 14

I've been wanting to drop the Nasa WorldWind SDK on my notebook so I can explore it a bit more on my own time. My notebook is a bit more unconventional than the lab systems. I keep the lab systems as close to standard as possible to minimize any installation or runtime issues. My notebook is more of a personal sandbox, a personal spot to tinker.

Up to this point everything's been run on Windows and 32-bit Linux. But this installation of Fedora 14 is 64-bit, and it introduced a few little quirks that had to be settled. Nothing major, but they need to be documented in one spot.

First is an SDK ant build quirk. I want to be able to run ant in the SDK folder if necessary from the command line and have the SDK re-build. When I tried a build right after unpacking the SDK I got a log of  "unmappable character for encoding UTF8" error message because somebody decided to include the degree symbol as part of a comment, and Java 6u29's javac decided it didn't like it. That tickled an old memory about some obscure javac command line arguments, so after looking up javac's documentation (again) I modified the stock build.xml's javac section and added the highlighted line:

        <javac 
            encoding="ISO-8859-1"
            srcdir="${worldwind.src.dir}"
            destdir="${worldwind.classes.dir}"
            source="${worldwind.jdk.version}"
            target="${worldwind.jdk.version}"
            fork="true"
            includeantruntime="false"
            memoryMaximumSize="512m">
            <classpath>
              <pathelement location="jogl.jar"/>
              <pathelement location="gluegen-rt.jar"/>
              <pathelement location="gdal.jar"/>
              <pathelement location="${java.home}/lib/plugin.jar"/>
            </classpath>
        </javac>

Once you add the encoding argument the Java classes will build. One other little gotcha. There is no simple clean. The target "clean.all" will clean everything. You should read the build.xml file for all the individual clean targets.

The next little quirk concerns the native libraries required by Jogl. The shared libraries under Linux are libgluegen-rt.so, libjogl_awt.so, libjogl_cg.so and libjogl.so, and they're located in the root folder where you unpack the SDK. They're compiled for a 32-bit Intel class processor, and you need the 64-bit versions. There's a page that explains what the problem is and the solution but it's a little obtuse, so I'm going to spell it out. To replace these libraries you need to go to http://download.java.net/media/jogl/builds/archive/jsr-231-1.x-webstart-current/ and download gluegen-rt-natives-linux-amd64.jar and jogl-natives-linux-amd64.jar. Un-jar them and move the resultant shared object files to the SDK folder to replace the 32-bit versions.

You need to make one more minor modification, this time to the script run_demo.bash. On the line executing java, add the following additional argument: -Djava.library.path=.
This will tell java to look for the library files in the location where it's executed from, which in this case is the SDK's base folder. You can make this more elaborate if you wish, but the bash script assumes you're going to run it out of the SDK folder. The classpath is already set up to look for the jar files in the same base folder the script is executed in.

And that's about it. All the java files build and the demo executes. Now I'm to the point where I can begin a bit of experimentation. The next task I want to perform is to install the Android library version of WorldWind and see if I can get something up and running on the Asus Transformer, and then begin to create the ability to share between the notebook version and the table version. I have some ideas...