622 2012-09-23 04:46:55 +0200 Changes required to build JOGL git master on Mac OS X 10.8 with Oracle JDK 2013-02-20 14:27:27 +0100 1 1 3 JogAmp Jogl macosx 2 pc_x86_64 macosx RESOLVED FIXED --- normal --- 0 jrh sgothel alexander.lex --- gluegen 4aa36ed61fd1bb434f2a5dd4d7dbffd6f87a446d gluegen e4fc97f6c08d58d1a62543fdfda92fddfda6ee68 gluegen 6b86764f2e195b4046000fd5a7fcf3331ca72d21 jogl fdc20a0205bb01747055910eb2bb33202edee277 jogl fc9539d50c12f9def7a3babde7384e3d38f61721 jogl a40ee817a3bd537b0de7018772b0835f995a1bed --- oldest_to_newest 1847 0 369 jrh 2012-09-23 04:46:55 +0200 Created attachment 369 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. 1930 1 alexander.lex 2012-10-30 15:33:30 +0100 We run into this problem and would really appreciate if the fix would be accepted asap! 1931 2 sgothel 2012-10-30 20:44:41 +0100 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! 1943 3 jrh 2012-10-31 23:32:52 +0100 (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. 2202 4 sgothel 2013-02-20 14:27:27 +0100 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. 369 2012-09-23 04:46:55 +0200 2012-09-23 04:46:55 +0200 Specify jawt_md.h from JavaVM.framework on Mac OS X. ensure-javavm-framework-jawt_md.patch application/octet-stream 984 jrh ZGlmZiAtLWdpdCBhL3NyYy9uYXRpdmV3aW5kb3cvbmF0aXZlL0pBV1RfRHJhd2luZ1N1cmZhY2VJ bmZvLmMgYi9zcmMvbmF0aXZld2luZG93L25hdGl2ZS9KQVdUX0RyYXdpbmdTdXJmYWNlSW5mby5j CmluZGV4IDJhNjY1MTAuLjgyOWRkMTkgMTAwNjQ0Ci0tLSBhL3NyYy9uYXRpdmV3aW5kb3cvbmF0 aXZlL0pBV1RfRHJhd2luZ1N1cmZhY2VJbmZvLmMKKysrIGIvc3JjL25hdGl2ZXdpbmRvdy9uYXRp dmUvSkFXVF9EcmF3aW5nU3VyZmFjZUluZm8uYwpAQCAtMzcsNyArMzcsMTEgQEAKICAqIGFuZCBk ZXZlbG9wZWQgYnkgS2VubmV0aCBCcmFkbGV5IFJ1c3NlbGwgYW5kIENocmlzdG9waGVyIEpvaG4g S2xpbmUuCiAgKi8KIAorI2lmZGVmIF9fQVBQTEVfXworI2luY2x1ZGUgPEphdmFWTS9qYXd0X21k Lmg+CisjZWxzZQogI2luY2x1ZGUgPGphd3RfbWQuaD4KKyNlbmRpZgogCiAjaWZkZWYgV0lOMzIK ICAgI2RlZmluZSBQTEFURk9STV9EU0lfU0laRSBzaXplb2YoSkFXVF9XaW4zMkRyYXdpbmdTdXJm YWNlSW5mbykKZGlmZiAtLWdpdCBhL3NyYy9uYXRpdmV3aW5kb3cvbmF0aXZlL21hY29zeC9PU1ht aXNjLm0gYi9zcmMvbmF0aXZld2luZG93L25hdGl2ZS9tYWNvc3gvT1NYbWlzYy5tCmluZGV4IDFj ZjQxZmMuLjViNGM4ZTUgMTAwNjQ0Ci0tLSBhL3NyYy9uYXRpdmV3aW5kb3cvbmF0aXZlL21hY29z eC9PU1htaXNjLm0KKysrIGIvc3JjL25hdGl2ZXdpbmRvdy9uYXRpdmUvbWFjb3N4L09TWG1pc2Mu bQpAQCAtMzcsNyArMzcsNyBAQAogI2luY2x1ZGUgImpvZ2FtcF9uYXRpdmV3aW5kb3dfbWFjb3N4 X09TWFV0aWwuaCIKICNpbmNsdWRlICJqb2dhbXBfbmF0aXZld2luZG93X2phd3RfbWFjb3N4X01h Y09TWEpBV1RXaW5kb3cuaCIKIAotI2luY2x1ZGUgPGphd3RfbWQuaD4KKyNpbmNsdWRlIDxKYXZh Vk0vamF3dF9tZC5oPgogI2ltcG9ydCA8SmF2YU5hdGl2ZUZvdW5kYXRpb24uaD4KIAogLy8gI2Rl ZmluZSBWRVJCT1NFIDEK