Compiling JOGL on OSX

OpenGL Development JOGL Development
#1

I’ve tried to compile JOGL on OSX (10.3) and I’ve run into big problems. I’ve got ant and antlr installed, but when I do
ant macosx
It runs through all the build steps but fails java.generate:
java.generate.check:

java.generate:
[gluegen] Exception in thread “main” java.lang.NoClassDefFoundError: antlr/TokenStreamException

BUILD FAILED
file:/Volumes/Tsimmes/Users/abegel/Developer/eandl/jogl/make/build.xml:524: GlueGen returned: 1

I’ve set antlr.jar variable in host.properties to the antlrall.jar from the antlr-2.7.2 download (antlr.jar didn’t work) and antlr successfully ran on a few things, but then fails here. I’ve verified that antlrall.jar does have antlr.TokenStreamException.class in it.
I’m using ant 1.5.3 that I built from source.

What can I do? I’ve tried using the prebuilt jogl.jar file from july 17, but that doesn’t work on my system (gives the following error on the first paint call:

java.lang.IndexOutOfBoundsException: 0
at java.nio.DirectIntBufferU.get(DirectIntBufferU.java:196)
at net.java.games.gluegen.runtime.StructAccessor.getIntAt(StructAccessor.java:118)
at net.java.games.jogl.impl.macosx.JAWT_MacOSXDrawingSurfaceInfo.cocoaWindowRef(JAWT_MacOSXDrawingSurfaceInfo.java:63)
at net.java.games.jogl.impl.macosx.MacOSXOnscreenGLContext.lockSurface(MacOSXOnscreenGLContext.java:233)
at net.java.games.jogl.impl.macosx.MacOSXOnscreenGLContext.makeCurrent(MacOSXOnscreenGLContext.java:134)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:153)
at net.java.games.jogl.impl.macosx.MacOSXOnscreenGLContext.invokeGL(MacOSXOnscreenGLContext.java:73)
at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:179)
at net.java.games.jogl.GLCanvas.paint(GLCanvas.java:92)
at sun.awt.RepaintArea.paint(RepaintArea.java:177)
at apple.awt.ContainerModel.paintDamagedArea(ContainerModel.java:105)
at apple.awt.PeerPaintEvent.dispatch(PeerPaintEvent.java:172)
at apple.awt.CocoaEvent$1.run(CocoaEvent.java:86)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at apple.awt.CocoaEvent.dispatch(CocoaEvent.java:45)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:230)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:183)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)

Thanks

Andy

#2

The first error is similar to ones I’ve seen where antlr.jar was placed in the Extensions directory instead of having the property antlr.jar point to it. There is another thread on OS X build problems which discusses this in detail. Basically if you have ANTLR in your Extensions directory, remove it.

I can’t think of why you would be getting that exception with the binaries that have been posted. I am pretty sure the binaries work fine for others on 10.3 DP1. My installation isn’t exactly identical to that but should be close enough and things work OK here. Make sure you have cleaned out any old versions, etc. For example, I have had no problems building with the antlr.jar from the 2.7.2 distribution as opposed to antlrall.jar.

#3

Nope, it’s not in my /Library/Java/Extensions folder. It’s in /usr/local/pkg/antlr-2.7.2/share/antlr-2.7.2/antlr.jar.

I did try downloading the JOGL build from July 2 and that works for me. I think the telltale sign here is the reference to cocoaWindowRef() which doesn’t exist in OSX 10.3’s jawt_md.h file (replaced by cocoaViewRef()). Maybe the july 17th build was a half-hearted attempt at OSX 10.2 compatiblity?

#4

There has been as of yet no real attempt at 10.2 compatibility.

#5

[quote]I did try downloading the JOGL build from July 2 and that works for me. I think the telltale sign here is the reference to cocoaWindowRef() which doesn’t exist in OSX 10.3’s jawt_md.h file (replaced by cocoaViewRef()). Maybe the july 17th build was a half-hearted attempt at OSX 10.2 compatiblity?
[/quote]
No, there is not and has never been a reference to the cocoaWindowRef member of that structure in the JOGL code. Some of the line numbers in that stack trace are also wrong. It looks like it was typed in manually rather than cut-and-pasted in. Is is possible that this is the case?

#6

The stack trace was cut and pasted in, no alterations were made.

If you download the July 17th build from the File Sharing section of this website and run javap -c on net.java.games.jogl.impl.macosx.JAWT_MacOSXDrawingSurfaceInfo, you’ll see a cocoaWindowRef() method.

Compiled from JAWT_MacOSXDrawingSurfaceInfo.java
public class net.java.games.jogl.impl.macosx.JAWT_MacOSXDrawingSurfaceInfo extends java.lang.Object {
public static int size();
public net.java.games.jogl.impl.macosx.JAWT_MacOSXDrawingSurfaceInfo();
public net.java.games.jogl.impl.macosx.JAWT_MacOSXDrawingSurfaceInfo(java.nio.ByteBuffer);
public java.nio.ByteBuffer getBuffer();
public net.java.games.jogl.impl.macosx.JAWT_MacOSXDrawingSurfaceInfo cocoaViewRef(long);
public long cocoaViewRef();
public net.java.games.jogl.impl.macosx.JAWT_MacOSXDrawingSurfaceInfo cocoaWindowRef(long);
public long cocoaWindowRef();
public net.java.games.jogl.impl.macosx.JAWT_MacOSXDrawingSurfaceInfo cgContextRef(long);
public long cgContextRef();
}

Granted, there’s also a cocoaViewRef() method.
And, if you disassemble the net.java.games.jogl.impl.macosx.MacOSXOnscreenGLContext class, the lockSurface() method calls cocoaViewRef(), not cocoaWindowRef(). So, I can’t explain what’s going on. All I know is that my error is quite repeatable.

There’s no other jogl in my CLASSPATH and none in /Library/Java/Extensions.

Perhaps someone could post a more up-to-date build, and perhaps this problem might go away?

Thanks.

Andy

#7

I can build mine again and post it later, but there have been no relevant CVS changes to the precompiled OSX binaries that are already on the site. If you’re using 10.3 (what release are you using?), it builds right from the source - with all its antlr madness.

#8

Thanks for posting a new build, even if there’s no real changes.
I tried compiling JOGL myself, but ran into the problem listed in my first message in this thread (that was unresolved by the helpful suggestions of the other replies). I’m less than amazed by ant, esp. re: classloaders and separating different java programs in the same JVM image (which is obviously where I’m having problems).

#9

Well the problem you’re describing doesn’t sound like it has anything do do with ant per say, as others seem to be able to check out of CVS and run everything just fine. What build of 10.3 are you using? Also let me know if your email address is correct and I will email you there as I don’t want to put a non official jogl build on the jogl site since no new features are going in or anything.

#10

FYI, the JOGL source tree has been updated to work with the most recent 10.3 build. I have heard that there is a plan to release that Java (and current JAWT) on 10.2; if that happens then JOGL will work on 10.2 after you run Software Update. It turns out your antlr.TokenStreamException problem was happening because you didn’t modify host.properties. I keep forgetting to do that myself so I’ve changed how the build process finds that file; see doc/HowToBuild.html for the revised info on jogl.properties.

At this point I should be able to produce new binaries on all platforms soon, possibly by tomorrow night.

#11

[quote]I have heard that there is a plan to release that Java (and current JAWT) on 10.2; if that happens then JOGL will work on 10.2 after you run Software Update.
[/quote]
That would be great! More for the consumer than the developer. Since most developers keep up to date with the latest OS releases, but consumers can often lag behind considerably (There are still Mac users using OS 9 !! And some of them prefer it!)

#12

Yeah, but they all have machines slower than my cellphone so it doesn’t matter all that much :slight_smile:

#13

Maybe so… but I recall that I first played Quake 1 on a 90 MHz Pentium I, with a software renderer.

Of course Java running on a machine over 20 times faster still can’t handle that… sigh… (software per-pixel rendering and Java will never be friends with the bounds checking overhead when accessing bitmaps pixel by pixel)

but with hardware 3D… even a lowly 350MHz machine should be decent for very many games done with Java…

I think of the old Amigas running at around 4MHz… it was the fancy hardware that made the games so impressive (e.g. Shadow of the Beast)…

So Java + OpenGL should yield some pretty fun stuff, but somehow computing power seems to disappear these days… The machines are hundreds of times faster than some old box like an Amiga… yet the games are nowhere near 100 times more impressive. Wherever all that computing power is going is sort of a mystery :).

Maybe that cell phone needs a video out jack… then it can serve as the next console too :wink:

#14

[quote]Wherever all that computing power is going is sort of a mystery
[/quote]
Abstraction layers, Eyecandy and last but not least: smaller time to market which yields unoptimized code.

#15

yeah yeah… I sort of know where it’s going… yet all those layers still seem to be taking more than their fair share of CPU power.

I think we need a new law to counter Moore’s law… actual CPU speed may double every X months, but perceived CPU power moves at a much slower rate :slight_smile:

Now if games these days actually played like this:
http://www.vividimage.co.uk/ActorDemo.htm
Then I would be impressed :).

#16

[quote]Maybe so… but I recall that I first played Quake 1 on a 90 MHz Pentium I, with a software renderer.

Of course Java running on a machine over 20 times faster still can’t handle that… sigh… (software per-pixel rendering and Java will never be friends with the bounds checking overhead when accessing bitmaps pixel by pixel)

but with hardware 3D… even a lowly 350MHz machine should be decent for very many games done with Java…

I think of the old Amigas running at around 4MHz… it was the fancy hardware that made the games so impressive (e.g. Shadow of the Beast)…

So Java + OpenGL should yield some pretty fun stuff, but somehow computing power seems to disappear these days… The machines are hundreds of times faster than some old box like an Amiga… yet the games are nowhere near 100 times more impressive. Wherever all that computing power is going is sort of a mystery :).

Maybe that cell phone needs a video out jack… then it can serve as the next console too :wink:
[/quote]
Be careful what you ask for - it may end up in the PSP :slight_smile:

In terms of games being 100 times more impressive, its like saying that movies aren’t 100 times more impressive. Games don’t get more impressive with technology IMO and I feel that the reliance on technology to make games impressive is what has game development in the rut its in now. I’ve played games with nasty graphics that are more fun that the more impressive wonders out there. Knights of the old republic for all its graphical coolness is actually not at the height of graphics rendering - but damn if it isn’t more fun that other games that look a lot bette :slight_smile: