Building git master on OS X 10.8

So, I jumped off the early-adopter cliff and installed OS X 10.8 this morning. Of course things are a bit broken. It seems that Apple has relocated the JDK _yet again_.  I was able to build by manually monkeypatching line 1404 of gluegen-cpp-tasks-base to point to "/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib" instead of "/System/Library/Frameworks/JavaVM.framework/Libraries" (which no longer exists). Longer-term, it seems like that should probably go inside a condition block along the lines of

<condition property="java.lib.dir.platform"
                 value="/System/Library/Frameworks/JavaVM.framework/Libraries"
                 else="/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib">
                 <available file="/System/Library/Frameworks/JavaVM.framework/Libraries/libjawt.dylib"/>
</condition>

Of course, this is not ideal because it hard-codes a reliance on the 1.7.0 JDK. There doesn't seem to be a generic symlink anywhere (that I've found, anyway) though that points to that path.

Any thoughts?  Hopefully this will at least get any other early adopters running into trouble back up and compiling, 'til a real fix is developed.

I guess 10.8 is still pretty new around these parts. I found this message when trying to build JOGL on my shiny new retina laptop (I'm sure that'll have plenty of its own problems). I can't seem to find the pre-built binaries anymore, so this is my first time attempting to build JOGL.

The change you found is part of the Apple/Oracle transition. You're right that hard-coding a "1.7.0.jdk" path is wrong (my newly-installed 7u7 Oracle JDK has "jdk1.7.0_07.jdk" there instead). There seem to be several places that need to change, e.g. setting java.home.dir to /System/Library/Frameworks/JavaVM.framework/Home. Under the new regime, java.home.dir on Mac OS X should be ${java.home}/.., just like everywhere else, and java.includes.dir.platform should be ${java.includes.dir}/darwin. There are probably a bunch of other similar changes that need to happen, but I'm not enough of an ANT guru to do it right and still maintain backwards compatibility.

Anyway, if you change java.home.dir to point to ${java.home}/.. on OS X, then java.lib.dir.platform can just be ${java.home.dir}/jre/lib. That seemed to work for me well enough to get other compiler errors instead. The first was that 7u7's jawt_md.h includes <X11/Xlib.h> and a couple of other X11 headers. X11.app has been replaced by XQuartz.app, which apparently now puts these headers in /opt/X11/include. So I added that path to compiler.cfg.macosx.nativewindow in build-nativewindow. Then I got conflicting definitions for Boolean from <X11/Intrinsic.h> (as int) and <MacTypes.h> (as unsigned char) when building c.build.nativewindow.windowlib.macosx. That's as far as I am now.

tl;dr: On OS X 10.8 with Oracle JDK 7, these are proper values:

java.home.dir := ${java.home}/..
java.includes.dir.platform := ${java.includes.dir}/darwin
java.lib.dir.platform := ${java.home.dir}/jre/lib

as well as the standard (i.e. non-Mac-specific) values for these two:

target.rt.jar := ${java.home}/lib/rt.jar
host.rt.jar := ${java.home}/lib/rt.jar

OK, I just got JOGL to build (whether or not it works is TBD) on a retina MBP, OS X 10.8.1, Oracle JDK 1.7.0_07. I had to make these changes to gluegen-cpptasks-base.xml:

macos32 := false (because the JDK's libawt.dylib isn't universal)
java.home.dir := ${java.home}/..
java.includes.dir.platform := ${java.includes.dir}/darwin
java.lib.dir.platform := ${java.home.dir}/jre/lib

What I said about X11 turned out not to be quite right. The actual solution to that and the Boolean thing was to make sure to include <JavaVM/jawt_md.h> instead of <jawt_md.h>. So in JAWT_DrawingSurfaceInfo.c, replace "#include <jawt_md.h>" with

#ifdef __APPLE__
#include <JavaVM/jawt_md.h>
#else
#include <jawt_md.h>
#endif

and in OSXmisc.m (which is only compiled on Mac anyway) just replace it unconditionally with "#include <JavaVM/jawt_md.h>".

On 09/22/2012 05:08 AM, jrh [via jogamp] wrote: Thank you. Maybe you can add your findings to bugzilla, so they don't get lost ?

Then .. we would need to put all this permanent w/o hurting other OSX
versions, then it would be ready for a git pull.

Thank you.

~Sven

Sven Gothel wrote

Thank you. Maybe you can add your findings to bugzilla, so they don't get lost ?

Is there an existing bug that I should add it to, or should I create a new one?

Sven Gothel wrote

Then .. we would need to put all this permanent w/o hurting other OSX
versions, then it would be ready for a git pull.

The source file #include changes I made should be usable as-is, i.e.

jogamp/jogl $ git diff
diff --git a/src/nativewindow/native/JAWT_DrawingSurfaceInfo.c b/src/nativewindow/native/JAWT_DrawingSurfaceInfo.c
index 2a66510..829dd19 100644
--- a/src/nativewindow/native/JAWT_DrawingSurfaceInfo.c
+++ b/src/nativewindow/native/JAWT_DrawingSurfaceInfo.c
@@ -37,7 +37,11 @@
  * and developed by Kenneth Bradley Russell and Christopher John Kline.
  */
 
+#ifdef __APPLE__
+#include <JavaVM/jawt_md.h>
+#else
 #include <jawt_md.h>
+#endif
 
 #ifdef WIN32
   #define PLATFORM_DSI_SIZE sizeof(JAWT_Win32DrawingSurfaceInfo)
diff --git a/src/nativewindow/native/macosx/OSXmisc.m b/src/nativewindow/native/macosx/OSXmisc.m
index 1cf41fc..5b4c8e5 100644
--- a/src/nativewindow/native/macosx/OSXmisc.m
+++ b/src/nativewindow/native/macosx/OSXmisc.m
@@ -37,7 +37,7 @@
 #include "jogamp_nativewindow_macosx_OSXUtil.h"
 #include "jogamp_nativewindow_jawt_macosx_MacOSXJAWTWindow.h"
 
-#include <jawt_md.h>
+#include <JavaVM/jawt_md.h>
 #import <JavaNativeFoundation.h>
 
 // #define VERBOSE 1

but my ANT skills aren't up to the task right now to provide patches that maintain sufficient backwards compatibility. I can tell you what the values should be for 10.8 with Oracle Java 7 (or OpenJDK 7, I would think), and if somebody else makes the changes to gluegen-cpptasks-base.xml I'll certainly volunteer to test them.

On 09/22/2012 07:50 PM, jrh [via jogamp] wrote:
>     Sven Gothel wrote
>     Thank you. Maybe you can add your findings to bugzilla, so they don't get
>     lost ?
>
> Is there an existing bug that I should add it to, or should I create a new one?
A new one pls.
>
>     Sven Gothel wrote
>     Then .. we would need to put all this permanent w/o hurting other OSX
>     versions, then it would be ready for a git pull.
>
> The source file #include changes I made should be usable as-is, i.e.

Are they working on _all_ platforms (i.e. also compile on OSX 10.7.* w/ Java6, and
all other supported platforms ?
The latter is the difficulty .. and for sure a bit annoying part.

~Sven

Sven Gothel wrote

On 09/22/2012 07:50 PM, jrh [via jogamp] wrote:
>     Sven Gothel wrote
>     Thank you. Maybe you can add your findings to bugzilla, so they don't get
>     lost ?
>
> Is there an existing bug that I should add it to, or should I create a new one?
A new one pls.

OK, will do. Just received the confirmation email so I can create a bugzilla account.

Sven Gothel wrote

>
>     Sven Gothel wrote
>     Then .. we would need to put all this permanent w/o hurting other OSX
>     versions, then it would be ready for a git pull.
>
> The source file #include changes I made should be usable as-is, i.e.

Are they working on _all_ platforms (i.e. also compile on OSX 10.7.* w/ Java6, and
all other supported platforms ?
The latter is the difficulty .. and for sure a bit annoying part.

Yes. For the one file I put the change inside of an #ifdef __APPLE__, and the other is only compiled on Mac OS X anyway. The path <JavaVM/jawt_md.h> should be fine on OS X for all previous versions of Java, as far as I know. That's what I've always used in the past, anyway. The compiler already knows how to interpret <Framework/header.h> to find the file at Framework.framework/Headers/header.h without requiring any -I flags; may as well take advantage of that.

Similarly, you guys are using

#import <JavaNativeFoundation.h>

 and then passing

<compilerarg value="-I${java.osx.frameworks.dir}/JavaNativeFoundation.framework/Headers" />

when you could do the slightly shorter

#import <JavaNativeFoundation/JavaNativeFoundation.h>

 and

<compilerarg value="-F${java.osx.frameworks.dir}" />

Of course really, the jawt_md.h inside of Oracle's JDK *should* work. I think it's a bug that they appear to be shipping a stock Unix (Solaris?) jawt_md.h instead of adopting Apple's. If that gets fixed, then this #include change could get reverted.

Bug submitted:
https://jogamp.org/bugzilla/show_bug.cgi?id=622