RFR (S): 7125793: MAC: test_gamma should always work (original) (raw)

Daniel D. Daugherty daniel.daugherty at oracle.com
Tue Jan 3 10:39:13 PST 2012

http://cr.openjdk.java.net/~jmelvin/7125793/webrev.00

Jim,

Thanks for diving in and improving the MacOS X port! Comments below.

Dan

make/bsd/makefiles/buildtree.make

 line 422: The new 'java -fullversion' invocation does not include
     the $(JAVA_FLAG) option like the old code did. Any particular
     reason for the change?

     Looks like that means the '-d32' or '-d64' options won't be
     specified as they were before.

 line 447: Why not just echo FULL_VERSION? Why pipe to awk?

 line 465: The 'jre/lib/libjava.dylib' part of the new check is
     MacOS X specific. Other BSDs don't necessarily use the
     '.dylib' extension (instead of .so) and I don't think that
     other BSDs have dropped the "arch" subdir.

 line 484: The DYLD_LIBRARY_PATH part is MacOS X specific. Will
     still need to set LD_LIBRARY_PATH for other BSDs.

 line 492: You switched from $(TESTFLAGS) to literal flag values,
     but you left the TESTFLAGS variable around. Any reason for
     the switch?

make/bsd/makefiles/launcher.make Please add a comment explaining why '-framework CoreFoundation' is needed. Your explanatory block below is a really good start.

make/bsd/makefiles/vm.make No comments.

src/os/bsd/vm/os_bsd.cpp line 2585: Uses a suffix of ".so". That shouldn't work on MacOS X since MacOS X uses '.dylib'. That's OK for other BSDs, but not MacOS X. Also the comments that mention '.so' should be updated to include '.dylib' (not caused by your changes).

 To David H. - Yes, this change added another '#fdef __APPLE__'. It
     is not the first and it likely won't be the last since we're
     not done yet with the MacOS X port. There are a number of
     things that need to be cleaned up and we're tracking them.
     However, as you know, we don't have enough folks to handle all
     of the work so we'll just have to live with the warts for now.

src/os/posix/launcher/java_md.c No comments.

On 12/31/11 1:39 AM, James Melvin wrote:

Hi,

This change fixes the 'gamma' simple launcher for HotSpot on Mac OS X. There were 3 primary changes required to re-enable gamma... 1) Statically link with CoreFoundation framework to resolve symbols The gamma launcher dlopen()s libjava.dylib from $JAVAHOME/jre/lib. Because Mac OS X files are case-insensitive by default, we collide on $FRAMEWORK/libJPEG.dylib and ${JAVAHOME}/jre/lib/libjpeg.dylib. This resulted in unresolved symbols in the Mac OS X framework libraries. The solution for gamma was to statically link with CoreFoundation framework to properly resolve framework symbols and allow gamma to successfully dlopen() libjava.dylib. 2) Adjust various paths to reflect no arch subdirs On Mac OS X, there are no arch subdirs, e.g jre/lib vs jre/lib/. Instead, one can use universal binaries to package multiple architectures in a single binary. At the moment though, we are only building 64-bit non-universal binaries. Note, the testgamma script assumes an Oracle JDK layout for JAVAHOME, derived from ALTBOOTDIR. Using an Apple JDK for ALTBOOTDIR will fail the testgamma script gracefully, as libjava.dylib is in a different, unexpected place. 3) Modify testgamma script to set library path only for gamma launch Setting DYLDLIBRARYPATH adversely affects the real java launcher(s). Instead, set this later in the script only for the gamma launcher test run. While in there, I took the liberty of decrypting the script to make it more maintainable and more easily merged whenever we reconcile the unix ports into a single codebase. There is no change to the script output. Feedback welcome... WEBREV: http://cr.openjdk.java.net/~jmelvin/7125793/webrev.00 TESTS RUN: JPRT 2011-12-31-061123.jmelvin.7125793 local Mac OS X builds/tests

Thanks and Happy New Year! Jim

More information about the macosx-port-dev mailing list