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

[Kelly O'Hair]

I was having similar concerns, but wasn't able to come up with a clean alternative at the time.

Having a ARCH_LIB_PATH_APPEND and a ARCH_BIN_PATH_APPEND might be better,
(I think bin and lib might use different names sometimes? Or they did once upon a time? bin/v9 lib/sparcv9?)

Anyway, I'd like to see the proprietary names left out. Or minimized. Or isolated to the Makefiles?

-kto

On Jan 2, 2012, at 9:41 PM, David Holmes wrote:

> Hi Jim,
> 
> I'm getting increasingly concerned about platform specific code being in, or being added to, what is nominally shared code, so I'd like to see if we can reduce some of that:
> 
> src/os/posix/launcher/java_md.c
> 
> Instead of the ifdef APPLE can we not factor out a JRE_LIB_PATH (or something like that) that is set to jre/lib or jre/lib/<arch> as appropriate by the platform specific build files? This would also allow the new case
> 
> /* Is the JRE universal, i.e. no arch dir? */
> 
> to be handled by the existing code.
> 
> ---
> 
> src/os/bsd/vm/os_bsd.cpp
> 
> Similar comment - use JRE_LIB_PATH instead of jre/lib/%s etc
> 
> ---
> 
> David
> -----
> 
> 
> 
> On 1/01/2012 2:43 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