<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <tt>Thanks Serguei!<br>
      <br>
      Dan<br>
      <br>
    </tt><br>
    On 4/12/12 4:02 PM, <a class="moz-txt-link-abbreviated" href="mailto:serguei.spitsyn@oracle.com">serguei.spitsyn@oracle.com</a> wrote:
    <blockquote cite="mid:4F8750DA.6070203@oracle.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Looks good.<br>
      <br>
      Thanks,<br>
      Serguei<br>
      <br>
      On 4/12/12 2:03 PM, Daniel D. Daugherty wrote:
      <blockquote cite="mid:4F874320.6010800@oracle.com" type="cite">The
        wonderful T&L nightly testing caught an error in my changes
        <br>
        that were reviewed on this thread. On Linux and Solaris, I
        installed <br>
        the .debuginfo files for programs in $JAVA_HOME/bin. I made a <br>
        mistake in the way I interpreted what I was seeing in the
        Windows <br>
        code and in $JAVA_HOME/jre/bin. Long story shorter... we
        shouldn't <br>
        install .debuginfo files for programs. <br>
        <br>
        7160895 3/3 tools/launcher/VersionCheck.java attempts to launch
        .debuginfo <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160895">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160895</a>
        <br>
        <br>
        The fix is a simple tweak to changes reviewed on this thread: <br>
        <br>
        diff -r d922195b678d make/common/Program.gmk <br>
        --- a/make/common/Program.gmk   Wed Apr 11 07:26:35 2012 -0700 <br>
        +++ b/make/common/Program.gmk   Thu Apr 12 13:38:36 2012 -0700 <br>
        @@ -268,6 +268,11 @@ else <br>
                   $(ZIPEXE) -q $(@F).diz $(@F).debuginfo ; \ <br>
                   $(RM) $(@F).debuginfo ; \ <br>
                  ) <br>
        +          # save ZIP'ed debug info with rest of the program's
        build artifacts <br>
        +          $(MV) $@.diz $(OBJDIR) <br>
        +        else <br>
        +          # save debug info with rest of the program's build
        artifacts <br>
        +          $(MV) $@.debuginfo $(OBJDIR) <br>
                 endif <br>
               endif # PROGRAM_SUPPORTS_FULL_DEBUG_SYMBOLS <br>
             endif # ENABLE_FULL_DEBUG_SYMBOLS <br>
        <br>
        After generation of the program's .debuginfo file, we move it <br>
        to the build directory that has the rest of build artifacts, <br>
        i.e., .o files etc. We generate the .debuginfo file in the bin <br>
        directory because that is where the link phase puts the program
        <br>
        binary in a Linux and/or Solaris build. <br>
        <br>
        On Windows, the program, the .map and the .pdb files are
        generated <br>
        in the build directory and only the program (.exe) is copied to
        <br>
        the bin directory. So in a Windows build, the program binary is
        <br>
        in the build directory and the bin directory and on Linux and <br>
        Solaris the program binary is only in the bin directory. <br>
        <br>
        Dan <br>
        <br>
        <br>
        On 4/9/12 2:51 PM, Daniel D. Daugherty wrote: <br>
        <blockquote type="cite">Greetings, <br>
          <br>
          Coming soon to a JDK repo near you! Full Debug Symbols! <br>
          <br>
          OK, to just a subset of libraries and programs... on Linux and
          Solaris... <br>
          If you're a Windows fan, the JDK repo has had Full Debug
          Symbols support <br>
          since way back in JDK1.4.1... Now we're trying get Linux and
          Solaris <br>
          caught up... <br>
          <br>
          Runtime Team, we don't have much in the JDK repo, but I tried
          to cover <br>
          our few libraries and programs. Let me know if I missed
          anything... <br>
          <br>
          Serviceability Team, all of your demos, libraries and programs
          are <br>
          covered... for some reason, updating those seemed like
          reliving old <br>
          times and I didn't think you'd mind... :-) <br>
          <br>
          Here is the webrev URL: <br>
          <br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edcubed/fds_revamp/7071907-webrev/0-jdk8-jdk/">http://cr.openjdk.java.net/~dcubed/fds_revamp/7071907-webrev/0-jdk8-jdk/</a>
          <br>
          <br>
          Thanks, in advance, for any review comments. <br>
          <br>
          Dan <br>
          <br>
          P.S. <br>
          For those of you that are keeping track of all the FDS <br>
          changesets, not everything has hit the various master <br>
          repos yet. As a reminder, FDS has to hit the closed <br>
          install repo first. The open root and jdk repos along <br>
          with the closed deploy repo are in the second wave. And <br>
          the hotspot repo, being more Mercurial than his fellow <br>
          ghosts, will make his appearance in his own good time <br>
          (and via a different set of repos)... <br>
          <br>
          Apologies to Dickens, of course... :-) <br>
          <br>
          <br>
        </blockquote>
      </blockquote>
      <br>
    </blockquote>
  </body>
</html>