ELFCLASS64 link error using solaris-sparcv9

I’m porting my application to a Sun Ultra 45 workstation (sol 10) and I’m linking with the JSR-231 1.1.0-rc2-January 23 libs.If I understand correctly, these are the 64bit libs, but my app is giving the following error on those libs …

Exception in thread “AWT-EventQueue-0” java.lang.UnsatisfiedLinkError: /home/me/Workspace/myApp/distrib/bin/jogl-1.1.0-rc2-solaris-sparcv9/lib/libjogl.so: ld.so.1: java: fatal: /home/me/Workspace/myApp/distrib/bin/jogl-1.1.0-rc2-solaris-sparcv9/lib/libjogl.so: wrong ELF class: ELFCLASS64
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)

Are these not the correct native libs? Am I doing something else wrong here?

Whether you should use the 32-bit or 64-bit SPARC libraries depends on which JVM you’re using. Unless you’re explicitly running java -d64 you are probably using the 32-bit JVM. java -version should tell you. Unless it reports you’re using the 64-bit Server VM, you’re using the 32-bit JVM and you should be using the 32-bit JOGL libraries.

I’ve got a similar issue, but the reverse.

We are building jogl on a Solaris box, but the libraries we get are 32 bit, when we want 64.

How do we specify that we want 64 bits? If I had a java call, I’d pass in -d64. But I’ve got a call to ant, and don’t know how to set this.

I’ve tried setting os.arch to sparcv9 (-Dos.arch=sparcv9), but this didn’t have any effect. If I write a Java program to output all the properties, I can see os.arch (as well as sun.arch.data.model) switching values depending on whether I put -d64 on the java command line. But I don’t know how to tell ant to send the right thing.

Or is there something else?

thanks,
andy

It’s a little magic – you need to set your PATH to pick up the java and javac which executes ant from the sparcv9 directory. At that point our build.xml will notice that os.arch is sparcv9 (instead of sparc) and take it from there.