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

[Daniel D. Daugherty]

> 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 $JAVA_HOME/jre/lib.
> Because Mac OS X files are case-insensitive by default, we collide on
> $FRAMEWORK/libJPEG.dylib and ${JAVA_HOME}/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/<arch>.
> 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 test_gamma script
> assumes an Oracle JDK layout for JAVA_HOME, derived from ALT_BOOTDIR.
> Using an Apple JDK for ALT_BOOTDIR will fail the test_gamma script
> gracefully, as libjava.dylib is in a different, unexpected place.
>
> 3) Modify test_gamma script to set library path only for gamma launch
>
> Setting DYLD_LIBRARY_PATH 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