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'.