Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8044480

JDK image target overwrites lib/server/libjsig.dylib symlink with a copy of lib/libjsig.dylib

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: infrastructure
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b17
    • CPU:
      x86_64
    • OS:
      os_x

      Description

      While helping Ron Durbin analyze the following bug:

          JDK-8038132 jprt bundles have libjsig.dylib in different place on OSX

      we observed a problem with the RE generated bits for MacOS X. I'm filing
      the bug for Ron because he's about to leave on vacation.

      $ pwd
      /java/re/jdk/1.9.0/latest/bundles/macosx-x86_64

      $ gzcat jdk-9-ea-bin-b15-macosx-x86_64-29_may_2014.tar.gz | tar tvf - | grep libjsig.dylib
      -rwxr-xr-x 502/20 15152 May 29 09:32 2014 jdk1.9.0.jdk/Contents/Home/jre/lib/libjsig.dylib
      -rwxr-xr-x 502/20 15152 May 29 09:32 2014 jdk1.9.0.jdk/Contents/Home/jre/lib/server/libjsig.dylib

      Notice that the two files are the same size and have the same timestamp.
      The second file, jre/lib/server/libjsig.dylib, is supposed to be a symlink
      to ../libjsig.dylib.

      Here's the Linux bits for an example:

      $ pwd
      /java/re/jdk/1.9.0/latest/bundles/linux-x64

      $ gzcat jdk-9-ea-bin-b15-linux-x64-29_may_2014.tar.gz | tar tvf - | grep libjsig.so
      -rwxr-xr-x 10/143 11052 May 29 09:36 2014 jdk1.9.0/jre/lib/amd64/libjsig.so
      -rwxrwxrwx 10/143 13 May 29 09:36 2014 jdk1.9.0/jre/lib/amd64/server/libjsig.so symbolic link to ../libjsig.so

      The Linux bits have an architecture subdir ('amd64') that is not present on
      the MacOS X bits; that because MacOS X uses a universal binary format.

      The jre/lib/server/libjsig.dylib symlink is created by the 'jdk' build process to
      refer to ../libjsig.dylib (aka jre/lib/libjsig.dylib) which is created by the 'hotspot'
      build process. Yes, it is strange for one repo to build the library and for another
      repo to create a symlink to that library. However, there is a good reason for it.
      The 'hotspot' build generates various libraries including libjsig.dylib and one or
      more libjvm.dylib libraries. The 'jdk' build imports various libraries from the
      'hotspot' build including one or more libjvm.dylib libraries. Each libjvm.dylib
      library is imported into its own directory in the jdk image. A symlink is created
      along side each libjvm.dylib to refer to ../libjsig.dylib. Only the 'jdk' build knows
      whether it will be creating the various VM subdirectories:

          jre/lib/client
          jre/lib/server

      so only the 'jdk' build knows which libjsig.dylib symlinks to create.


      Here's some analysis of the RE build log:

      $ pwd
      /java/re/jdk/1.9.0/latest/logs

      In build-macosx-x86_64.log, here's where the 'jdk' build creates the symlink:

         8292
         8293 ## Starting jdk
      <snip>
         8369 /bin/rm -f /HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/jdk/lib/server/libjsig.dylib
         8370 /bin/ln -s ../libjsig.dylib /HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/jdk/lib/server/libjsig.dylib


      And here's where the 'images' target blows away the symlink with a copy of the library:

        21905
        21906 ## Starting images
      <snip>
        30425 /bin/echo Copying images/j2re-bundle/jre1.9.0.jre/Contents/Home/lib/server/libjsig.dylib
        30426 Copying images/j2re-bundle/jre1.9.0.jre/Contents/Home/lib/server/libjsig.dylib
        30427 /bin/mkdir -p /HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/images/j2re-bundle/jre1.9.0.jre/Contents/Home/lib/server
        30428 /bin/echo Copying images/j2re-bundle/jre1.9.0.jre/Contents/Home/lib/server/libjvm.diz
        30429 if [ -d "/HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/images/j2re-image/lib/server/libjsig.dylib" ]; then /bin/mkdir -p /HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/images/j2re-bundle/jre1.9.0.jre/Contents/Home/lib/server/libjsig.dylib; else /bin/cp -f -R -L '/HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/images/j2re-image/lib/server/libjsig.dylib' '/HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/images/j2re-bundle/jre1.9.0.jre/Contents/Home/lib/server/libjsig.dylib'; fi
        30430 Copying images/j2re-bundle/jre1.9.0.jre/Contents/Home/lib/server/libjvm.diz

      The above copy is done like this: /bin/cp -f -R -L ...

      As an aside, I included lines 30428 and 30430 even though they are for the
      libjvm.siz file because they show that these two targets are running in parallel.
      Don't know if that is intentional, but it certainly makes me worry.

      So what's wrong with that ' /bin/cp -f -R -L' command? Well, the man page for cp
      on MacOS X says:

          -L If the -R option is specified, all symbolic links are followed.

      Earlier in the 'images' target, the server/libjsig.dylib symlink is copies properly:

        22907 /bin/echo Copying images/j2re-image/lib/server/libjsig.dylib
        22908 Copying images/j2re-image/lib/server/libjsig.dylib
        22909 /bin/mkdir -p /HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/images/j2re-image/lib/server
        22910 /bin/cp -fRP '/HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/jdk/lib/server/libjsig.dylib' '/HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/images/j2re-image/lib/server/libjsig.dylib'
        22911 if [ -n "`/usr/bin/xattr -l '/HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/images/j2re-image/lib/server/libjsig.dylib'`" ]; then /usr/bin/xattr -c '/HUDSON3/workspace/9-2-build-macosx-x86_64/jdk9/651/build/macosx-x86_64/images/j2re-image/lib/server/libjsig.dylib'; fi

      The "/bin/cp -fRP ..." is the right way to go...


      Here's the code that's doing the wrong version of cp:

      dev-clone/jdk/make/Bundles.gmk:

           32 ifeq ($(OPENJDK_TARGET_OS), macosx)
      <snip>
           77 # The old builds implementation of this did not preserve symlinks so
           78 # make sure they are followed and the contents copied instead.
           79 # To fix this, remove -L
           80 # Copy empty directories (jre/lib/applet).
           81 $(JDK_BUNDLE_DIR)/Home/%: $(JDK_IMAGE_DIR)/%
           82 $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@)
           83 $(MKDIR) -p $(@D)
           84 if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' '$@'; fi
           85
           86 $(JRE_BUNDLE_DIR)/Home/%: $(JRE_IMAGE_DIR)/%
           87 $(ECHO) Copying $(patsubst $(OUTPUT_ROOT)/%,%,$@)
           88 $(MKDIR) -p $(@D)
           89 if [ -d "$<" ]; then $(MKDIR) -p $@; else $(CP) -f -R -L '$<' '$@'; fi

      I love the comment. Actually, to fix this, you need to replace the '-L' with '-P'.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                erikj Erik Joelsson
                Reporter:
                dcubed Daniel Daugherty
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: