I only got a bug report for Linux and can't test AIX. A quick look at
the makefiles for AIX, I think you are probably fine. At least the weird
construct in the Linux makefiles is not there to mess things up.
/Erik
On 2015-12-17 07:49, Thomas Stüfe wrote:
Hi Eric,
short question, are other platforms beside Linux affected or is this
Linux-specific (I saw you said Windows x64 showed no regression)?
Reason I ask is, we just changed the default for AIX to "internal"
because this is the only configuration we support and the build was
broken after JDK-8036003 (see
https://bugs.openjdk.java.net/browse/JDK-8145560)
Kind Regards, Thomas
On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson
<erik.joels...@oracle.com <mailto:erik.joels...@oracle.com>> 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/
<http://cr.openjdk.java.net/%7Eerikj/8145564/webrev.01/>
/Erik
