> 17 mars 2018 kl. 00:16 skrev Erik Joelsson <erik.joels...@oracle.com>: > > 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 > <http://cr.openjdk.java.net/~erikj/8199749/webrev.01/index.html>
Looks good to me. /Magnus > > /Erik >
