JOGL Installation on MAC OSX - No Matching Architecture in Universal Wrapper

OpenGL Development JOGL Development
#1

hey guys,

i want to install and use JOGL on MAC OS X 10.6.2 but i have some problems and it doesnt work …

how i installed it: i’ve downloaded the latest version for mac (universal) from http://download.java.net/media/jogl/builds/archive/ . then i copied jogl.jar and gluegen-rt.jar together with libjogl_awt.jnilib, libjogl_cg.jnilib and libjogl.jnilib into /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext

this is my current directory of the latest java version which is also defined in eclipse so that it uses java 1.6.0

if i want to execute my first test project i get this error:

Exception in thread “main” java.lang.UnsatisfiedLinkError: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/libjogl.jnilib: no suitable image found. Did find: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/libjogl.jnilib: no matching architecture in universal wrapper
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1861)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1754)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1045)
at com.sun.opengl.impl.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:189)
at com.sun.opengl.impl.NativeLibLoader.access$000(NativeLibLoader.java:49)
at com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(NativeLibLoader.java:80)
at com.sun.opengl.impl.NativeLibLoader.loadLibrary(NativeLibLoader.java:103)
at com.sun.opengl.impl.NativeLibLoader.access$200(NativeLibLoader.java:49)
at com.sun.opengl.impl.NativeLibLoader$1.run(NativeLibLoader.java:111)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.opengl.impl.NativeLibLoader.loadCore(NativeLibLoader.java:109)
at com.sun.opengl.impl.macosx.MacOSXGLDrawableFactory.(MacOSXGLDrawableFactory.java:53)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:108)
at javax.media.opengl.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:520)
at javax.media.opengl.GLCanvas.(GLCanvas.java:131)
at javax.media.opengl.GLCanvas.(GLCanvas.java:90)
at JoglFrame.(JoglFrame.java:15)
at JoglFrame.main(JoglFrame.java:41)

anyone some ideas of how to solve this ?

i tried so much, downloaded it again and again, installed it here and there, read tons of installing tutorials and advices … dont know what to do. please help me :slight_smile:

#2

The jnilib files should not be put into /lib/ext/ but rather in /bin. This is a dirty way of installing JOGL. Please have a look here in the section concerning JOGL:
http://tuer.sourceforge.net/download.php

Let me know if it works.

#3

Could it be you are running 64 bit Java and don’t have 64 bit native libs for JOGL?

#4

I don’t think so. Look at where he put the jnilib files, it is the wrong directory, it should not be the same than for the JARs. Maybe he will discover a second problem like the one you’re talking about.

#5

okay … so the jnilib files are the native libraries where everywhere is talked about, am i right?

and i found that putting the native libraries into the “/bin” folder is only suitable for windows operating systems, so do i have to do that on mac too?

second thing: you say putting those libraries into my java folder is a dirty way? but otherwise i had to implement those libraries everytime i begin a new project, do i? uuhm …

and another question: if i export a project into a jar file, then eclipse puts all files into this jar, so nobody has to install JOGL if he wants to play this game? thats what i’m thinking, dont know exactly if i’m not wrong.

so i’ll try to solve this issue and post something if it works or not. thanks for your replies.

i don’t know if 64bit java is running and which libs i have? in the download section of jogl was only one latest release for mac (universal bin), so i did not have to choose.

#6

The problem with storing the jars and native libraries within the Java package for Mac is that it’s the first place searched when trying to resolve classes, etc. This means that anyone that tries to use JOGL will end up using the JOGL library and version you’ve placed there even if they wanted a different version.

Additionally, placing them in that directory makes them hard to keep track of. It is considered best practice to contain all necessary libraries for a project within the project itself. Eclipse lets you easily set this up when jars require native libraries. Within the build-path editor, add the jogl.jar and gluegen-rt.jar to the project, and then within each of those, there’s an option to specify the directory that holds their native libraries.

Your concern over needing to duplicate the libraries everywhere is often insignificant compared with the troubles caused by placing the jars in inappropriate locations. Additionally, the folder structure created by the method outlined above allows for much easier distribution than requiring users to locate and add JOGL to their Java’s directory.

#7

so, i removed all jogl files from /lib/ext in the java directory and placed them instead in my project folder. then i added them to the class path and added the native libraries too (as you see on the screenshot).


http://www.xup.in/pic,13107640/Bildschirmfoto_2010-03-28_um_21.48.27.png

but now there’s the same problem again:

[quote]Exception in thread “main” java.lang.UnsatisfiedLinkError: /Users/Lucas/Programmierung/Java/Eclipse/FirstJOGL/lib/libjogl.jnilib: no suitable image found. Did find: /Users/Lucas/Programmierung/Java/Eclipse/FirstJOGL/lib/libjogl.jnilib: no matching architecture in universal wrapper
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1861)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1778)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1045)
at com.sun.opengl.impl.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:189)
at com.sun.opengl.impl.NativeLibLoader.access$000(NativeLibLoader.java:49)
at com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(NativeLibLoader.java:80)
at com.sun.opengl.impl.NativeLibLoader.loadLibrary(NativeLibLoader.java:103)
at com.sun.opengl.impl.NativeLibLoader.access$200(NativeLibLoader.java:49)
at com.sun.opengl.impl.NativeLibLoader$1.run(NativeLibLoader.java:111)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.opengl.impl.NativeLibLoader.loadCore(NativeLibLoader.java:109)
at com.sun.opengl.impl.macosx.MacOSXGLDrawableFactory.(MacOSXGLDrawableFactory.java:53)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:108)
at javax.media.opengl.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:520)
at javax.media.opengl.GLCanvas.(GLCanvas.java:131)
at javax.media.opengl.GLCanvas.(GLCanvas.java:90)
at JoglFrame.(JoglFrame.java:15)
at JoglFrame.main(JoglFrame.java:40)
[/quote]
the version of JOGL i use is jsr-231-1.1.1-rc8 from http://download.java.net/media/jogl/builds/archive/ … but i don’t know if i need version 2 to make it fit to snow leopard? and i was concerned whether version 2 of jogl which is only in beta status is appropriated for developing or should i wait for its final release? thanks for answering

ps: so could it be that JOGL 1.x is too old to work with OS X 10.6.2 and therefore it finds no suitable architecture in this native library … for me that would sound logical.

#8

I’ve been using JOGL 2 for quite some time now on my Mac 10.6.2 and haven’t had these troubles. I also was able to get JOGL 1.1.1 working a long time ago but I think I switched to JOGL 2 before I upgraded from 10.5 to 10.6

#9

Under Linux, it is rather /lib/i386 but I have no Mac. It would be better not to put all these files inside the JVM. Give a try to JOGL 2 and let us know.

#10

[quote]no matching architecture in universal wrapper
[/quote]
I Got MacOSX snow lepord the other day, and IT SUXXXXXXX!!!

point being you need to include -d32 in the vm command line. to force java to run in 32 bit more.

#11

uuhm there is no /lib/i386 folder on mac. but that doesnt matter if i store the jogl library in my project directory.

how can i do this in eclipse? then i’d give it a try.

edit: i tried it but the error remains the same. did you mean that? or how do i add this command to the command line?

http://www1.xup.in/exec/ximg.php?fid=76032545

#12

Run as-> run configuration-> (x) Arguements ->Program arguements:
-D32

->apply

#13

please see my reply above :slight_smile:

#14

sorry, do a small “d” instead
therefore
-d32

#15

oh my god, so great, it works :smiley: thanks a lot!!

#16

Let this be a lesson to ya! :slight_smile:

#17

Happy to hear about the -d32 trick!

I previously tried to send a Jogl 1.x application of mine to someone running Snow Leopard and it didn’t work (the well-known “missing architecture” problem…)
Unfortunately, trying to convert the application to Jogl 2 was a nightmare (finally gave up…)

Now, sorry for the ignorance (backed-up by a lack of access to Snow Leopard), but I have this Mac newbie question:

My preferred mean of packaging the application for “easy end-user installation” was to make an executable Jar file.
Now, if have to use a VM argument, the solution is probably to invoke java on the command line.

On window, I would just send a .bat file for the guy to double-click on.

But on Mac, it sounds more complicated, like:

  • send a .sh file
  • ask the guy to open a terminal
  • ask the guy to “sudo su”
  • ask the guy to “chmod +x” on the script
  • and then only: have him execute the script

Or is there any simpler mean that I hopefully missed?

#18

There is a Mac application called Jar Bundler that is included with the Developer suite that seems pretty slick. It takes a jar and creates an application bundle that appears like any other Mac app. It also seems to have fields for VM options. I haven’t personally tried it, but I think that might be a place to look if you have access to a Mac.

edit There also appears to be a source forge project that allows you to perform the jar bundling using an Ant project. I think this might be platform independent.

#19

What you want is a Mac app bundle. Eclipse for OS X can export one.

#20

Java Web Start ;D

Edit.: Izpack allows you optionally to produce a bundle for Mac, it is a better but more complicated solution.