On Mar 17, 2011, at 2:47 PM, Sam Pullara wrote: > This appears to still be broken when I try and build. Has the change that > caused this been identified?
I can build and test 292 after backing out a linker argument change in Defs-bsd.make. I've put this change in mlvm as a separate patch named "bsd.patch". But, I haven't wrapped my brain around the interactions between the recent launcher changes and the Mac OS X dynamic linker. The Apple man page has this comment: > Unlike many other operating systems, Darwin does not locate dependent > dynamic libraries via their leaf file name. Instead the full path to each > dylib is used (e.g. /usr/lib/libSystem.B.dylib). But there are times > when a full path is not appropriate... [ http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/dyld.1.html ] The launcher $JAVA_HOME/bin/java dynamically loads one of $JAVA_HOME/jre/lib/i386/{client,server}/libjvm.dylib depending on a command line switch. It is important that any further linkage to libjvm.dylib not perform new loading (which was the bug) but resolve back to the previous load (whether client or server). Shortly after, the launcher then loads $JAVA_HOME/jre/lib/i386/libverify.dylib which has a dependency on libjvm. Somehow the dynamic linker needs to know that dependency refers to the previous (client or server) libjvm.dylib, instead of trying to load a fresh copy of libjvm. I don't know how this works, and I suspect it is fragile. Here's an easy way to observe what's going on with shared libraries: $ env DYLD_PRINT_{LIBRARIES,APIS}=1 $JAVA7_HOME/bin/java -client -version $ env DYLD_PRINT_{LIBRARIES,APIS}=1 $JAVA7_HOME/bin/java -server -version $ env DYLD_PRINT_{LIBRARIES,APIS}=1 $JAVA7_HOME/bin/java -d64 -version etc. -- John
