On 2015-12-17 01:40, David Holmes wrote:
On 17/12/2015 7:35 AM, Erik Joelsson wrote:
One more thing, where should this fix be pushed? Do you need it urgently
in hs-rt?
It is urgently needed in both the hs-rt and hs-comp repos as it
affects nightly testing and JPRT. If Alejandro agrees I suggest
pushing to jdk9/hs and it can then be pulled down to the team repos.
Will do.
With regard to the fix ... previously DEBUG_BINARIES was never set in
spec.gmk and so was never externally introduced into the hotspot build
this way. So why not simply change the name of the variable so that it
has no affect on the hotspot part of the build?
Well, we don't want it affecting the jdk part of the build either at
this point. This patch aims to restore the "external" and "zipped"
settings to exactly what they were before the patch, as was promised.
We will followup with a more complete fix.
/Erik
Thanks,
David
/Erik
On 2015-12-16 22:34, Erik Joelsson wrote:
Hello,
Please review this quick fix for the build issue introduced in Hotspot
by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true
when building Hotspot fastdebug, you essentially get a slowdebug
build. For an explanation of why, see comment in bug. This behavior is
of course also a bug, but not something I will address in this quick
fix.
What happened in JDK-8036003 was that a new configure API for
controlling debug symbols was introduced. The two main settings of
this new parameter, --with-native-debug-symbols, that we use
internally at Oracle are "external" and "zipped". It was important to
us that the behavior of these did not change with JDK-8036003, but
exactly that did happen, because both of these settings now cause
DEBUG_BINARIES=true to be set. This variable has never been set by
configure before and because of the above weird behavior in the
Hotspot makefiles, we are having problems.
My proposed quick fix is to not set DEBUG_BINARIES=true for "external"
or "zipped". It can remain true for "internal" since Oracle never
builds it that way, and I understand those that requested this new
configure parameter were setting DEBUG_BINARIES=true as a workaround
before this anyway, so they should be fine with the broken fastdebug
behavior for a while more. I will file a follow up bug to properly
clean up this mess, but it will take some more time.
Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
/Erik
