RFR: JDK-8199749: Debug symbols are not copied to exploded image on Mac

[Erik Joelsson]

Debug symbols are by default external and the idea is that we copy them 
to the exploded image together with the native libraries, to have them 
available for debugging. This logic fails on Windows and Mac due to some 
intricate make dependency complications. On Windows this fails on the 
initial build already, on Mac the problem only appears if you make a 
change to a source file and rebuild incrementally. On both, if you 
rebuild again, the files get copied.

On Solaris and Linux we symlink these files instead of copying, so after 
the first build, the symlinks do not need to be recreated, which is why 
this isn't an issue there.

The underlying cause for this is that we are trying to trick make into 
correctly tracking dependencies when a rule has multiple targets. The 
link rule creates both the native library as well as the debuginfo 
files. A rule like that is always causing trouble in some way but 
various workarounds exist. Currently we work around it by adding this 
declaration:

$$($1_DEBUGINFO_FILES): $$($1_TARGET)

This trips up make if DEBUGINFO_FILES already exists, since there is no 
recipe, make will not consider DEBUGINFO to have been updated just 
because TARGET was rebuilt. If we add a recipe, make will consider 
DEBUGINFO to have changed. The obvious recipe is a simple touch on 
DEBUGINFO. That way we also guarantee that the DEBUGINFO is newer than 
TARGET so the rule doesn't get executed again on the next run.

This whole type of workaround for dealing with multiple files created by 
the same rule has a flaw. If something external deletes a DEBUGINFO 
file, it would currently not be recreated. In the new solution it would 
be touched as an empty file, which is even worse. To fix this, I've 
added a parse time check on the DEBUGINFO files and if either of them 
are gone, the TARGET is explicitly deleted. This forces a rebuild of 
both TARGET and DEBUGINFO.

While at it, I noticed that the import library on Windows suffers from 
the same problem so applied the same fix there.

Bug: https://bugs.openjdk.java.net/browse/JDK-8199749

Webrev: http://cr.openjdk.java.net/~erikj/8199749/webrev.01/index.html

/Erik