You still have repeated patterns like: 131 ( set -e ; \ 132 cd $(XLIBJVM_DIR) ; \ 133 $(ADD_GNU_DEBUGLINK) $(LIBJVM_DB_DEBUGINFO) $(LIBJVM_DB) ; \ 134 ) When 131 ( cd $(XLIBJVM_DIR) && $(ADD_GNU_DEBUGLINK) $(LIBJVM_DB_DEBUGINFO) $(LIBJVM_DB) ) does the same thing and is more obvious, no need for the set -e
-kto On Jun 20, 2012, at 9:23 AM, Daniel D. Daugherty wrote: > Greetings, > > I've updated the fix to (hopefully) address Kelly's and David H's > concerns. Here is the URL for code review round 1: > > http://cr.openjdk.java.net/~dcubed/fds_revamp/7175255-webrev/1/ > > Brief summary of changes relative to code review round 0: > > - removed definition of GENERATED from both add_gnu_debuglink.make > and fix_empty_sec_hdr_flags.make; this will decouple these work > around Makefiles from the regular HotSpot Makefiles that define > the GENERATED macro. No, I'm not cleaning up that mess. :-) > - add new "XLIBJVM_DIR = 64" variable and change all uses of a > literal "64" in dtrace.make to the new variable > - drop uses of $(QUIETLY) in sub-shell constructs; I don't think > $(QUIETLY) works in sub-shells anyway, but my memory is fuzzy > there > > Test JPRT jobs for HSX-24 and HSX-23.2 are in flight right now. > > Thanks, in advance, for any reviews! > > Dan > > > On 6/19/12 7:21 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> This is an URGENT code review request for a Solaris specific Full Debug >> Symbols (FDS) fix. Due to a Makefile logic error, the full debug symbol >> files and related '_g' symlinks are created in the wrong sub-directory >> for a couple of the dtrace libraries. The incorrect paths have a double >> "64/" sub-directory, e.g.: >> >> solaris-<arch>/jre/lib/<arch>/client/64/64/libjvm_db.debuginfo >> >> These are the correct symlink paths: >> >> solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_g_db.debuginfo >> >> solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_g_dtrace.debuginfo >> solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_g_db.debuginfo >> >> solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_g_dtrace.debuginfo >> >> and these are the correct debug info file paths: >> >> solaris-<arch>/jre/lib/<arch>/client/64/libjvm_db.debuginfo >> solaris-<arch>/jre/lib/<arch>/client/64/libjvm_dtrace.debuginfo >> solaris-<arch>/jre/lib/<arch>/server/64/libjvm_db.debuginfo >> solaris-<arch>/jre/lib/<arch>/server/64/libjvm_dtrace.debuginfo >> solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_db.debuginfo >> solaris-<arch>/fastdebug/jre/lib/<arch>/client/64/libjvm_dtrace.debuginfo >> solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_db.debuginfo >> solaris-<arch>/fastdebug/jre/lib/<arch>/server/64/libjvm_dtrace.debuginfo >> >> where "<arch>" is "i586" or "sparc". The 64-bit Solaris platforms ("amd64" >> and "sparcv9") don't have this issue because they don't have the "64/" >> sub-directories. >> >> This fix is targeted at HSX-24/JDK8 and HSX-23.2/JDK7u6 and will resolve >> an issue that is preventing Oracle's Release Engineering scripts from >> running properly. >> >> Here is the webrev URL for the HSX-24/JDK8 version: >> >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7175255-webrev/0/ >> >> The HSX23.3/JDK7u6 version is the same except for the changes to >> make/solaris/makefiles/defs.make which are not needed in HSX23.2. >> >> Thanks, in advance, for any reviews! >> >> Dan >>
