| Summary: | Changes required to build JOGL git master on Mac OS X 10.8 with Oracle JDK | ||
|---|---|---|---|
| Product: | [JogAmp] Jogl | Reporter: | jrh |
| Component: | macosx | Assignee: | Sven Gothel <sgothel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander.lex |
| Priority: | --- | ||
| Version: | 2 | ||
| Hardware: | pc_x86_64 | ||
| OS: | macosx | ||
| 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. | ||
We run into this problem and would really appreciate if the fix would be accepted asap! 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! (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. 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. |
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.