Bug 622 - Changes required to build JOGL git master on Mac OS X 10.8 with Oracle JDK
Summary: Changes required to build JOGL git master on Mac OS X 10.8 with Oracle JDK
Status: RESOLVED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: macosx (show other bugs)
Version: 2
Hardware: pc_x86_64 macosx
: --- normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2012-09-23 04:46 CEST by jrh
Modified: 2013-02-20 14:27 CET (History)
1 user (show)

See Also:
Type: ---
SCM Refs:
gluegen 4aa36ed61fd1bb434f2a5dd4d7dbffd6f87a446d gluegen e4fc97f6c08d58d1a62543fdfda92fddfda6ee68 gluegen 6b86764f2e195b4046000fd5a7fcf3331ca72d21 jogl fdc20a0205bb01747055910eb2bb33202edee277 jogl fc9539d50c12f9def7a3babde7384e3d38f61721 jogl a40ee817a3bd537b0de7018772b0835f995a1bed
Workaround: ---

Attachments
Specify jawt_md.h from JavaVM.framework on Mac OS X. (984 bytes, application/octet-stream)
2012-09-23 04:46 CEST, jrh 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description jrh 2012-09-23 04:46:55 CEST 
Created attachment 369 [details]
Specify jawt_md.h from JavaVM.framework on Mac OS X.

Apple has transitioned responsibility for Mac Java over to Oracle. To accommodate this, they've rearchitected how JDKs/JREs are installed, and actually have brought relative paths closer in line with standard Java.

${java.home} will now be something like /Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/
and it will have the standard layout with {bin,include,jre/bin,jre/lib,lib}.

Several properties in gluegen/make/gluegen-cpptasks-base.xml currently assume the old Apple JavaVM.framework layout and need to be updated in order to get JOGL to compile on Mac OS X 10.8 (Mountain Lion) with an Oracle-provided JDK 1.7:

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


I also had to set

macos32 := false

because the libjawt.dylib in Oracle's JDK 1.7.0_07 build is 64-bit-only and so I got a link error when trying to build 32-bit. The values of macos32 and the others should probably depend upon the results of `file ${java.lib.dir.platform}/libjawt.dylib`.


Unfortunately, I'm not enough of an ANT wizard to figure out the right way to set all of those values while maintaining backwards compatibility with Apple's Java SE 6. (AFAICT the issue is only with the JDK vendor change and not OS changes per se.)



I also had to work around what I *think* is an Oracle JDK bug (but may be a design choice): it ships with a jawt_md.h set up for X11-based GUIs and not Apple's AppKit-based one (which defines the JAWT_SurfaceLayers ObjC protocol). Fortunately, JavaVM.framework still ships with Apple's implementation of this header, so I just had to make sure that we were including the correct one.

JAWT_DrawingSurfaceInfo.c changes like this:
+#ifdef __APPLE__
+#include <JavaVM/jawt_md.h>
+#else
 #include <jawt_md.h>
+#endif

and OSXmisc.m changes like this:
-#include <jawt_md.h>
+#include <JavaVM/jawt_md.h>

(See the attached git diff.)

Prior to Oracle Java, it was always this same jawt_md.h inside of the JavaVM framework that was being included, so this change *should* be fully backwards compatible, but someone with Mac OS X 10.{5,6,7} handy should double check.
Comment 1 alexsb 2012-10-30 15:33:30 CET 
We run into this problem and would really appreciate if the fix would be accepted asap!
Comment 2 Sven Gothel 2012-10-30 20:44:41 CET 
If this 'patch' is actually important to you - please send a pull request to one of your git branches.
This must be in sync w/ my latest master ofc.

Then I can easily test your patch.

Note: 
I haven't verified this patch manually yet, since I still build on java6
due to our compatibility baseline.
However, since we provide JNI headers and it's include path, 
I was under the impression this should not be necessary.

If I get a git pull request, I will give it a try and test on both variation.

Disclaimer:
This is low prio right now until RC11 is delivered, so probably next week!
Comment 3 jrh 2012-10-31 23:32:52 CET 
(In reply to comment #2)
> If this 'patch' is actually important to you - please send a pull request to
> one of your git branches.
> This must be in sync w/ my latest master ofc.

I assure you that it is important to me, but I don't know what this means (git noob, sorry). I take it that it's something other than giving you the output of "git diff", which is what I had attached here.

> 
> Then I can easily test your patch.
> 
> Note: 
> I haven't verified this patch manually yet, since I still build on java6
> due to our compatibility baseline.

So the compatibility baseline is 1.6? Any idea when that'll get bumped to 1.7? A lot of the Mac quirkiness in the build system can get simplified if we can assume Oracle/OpenJDK 1.7+.

> However, since we provide JNI headers and it's include path, 
> I was under the impression this should not be necessary.

I don't understand this statement, either, sorry. What should not be necessary? The "<JavaVM/jawt_md.h>" part? That's a workaround for the 1.7 JDK. Normally you'd want to use its jawt_md.h (at ${java.includes.dir.platform}), but Oracle's jawt_md.h is buggy, see:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181710
so we use the older one from Apple's JavaVM.framework instead. This change should be viewed as a temporary workaround, to be reverted once the JDK gets fixed.

> 
> If I get a git pull request, I will give it a try and test on both variation.
> 
> Disclaimer:
> This is low prio right now until RC11 is delivered, so probably next week!

Fine with me, I'm plenty busy with non-Java stuff right now.
Comment 4 Sven Gothel 2013-02-20 14:27:27 CET 
See referenced git sha1 values of gluegen + jogl.

GlueGen and JOGL can be build solely w/ Java7 w/o Java6 dependencies, 
further more - the build w/ Java6 or Java7 no more links against a Java6 native library,
which was previously the case.