RFR: JDK-8167479: arm 32/64 slowdebug fails to build on unpack200
david.holmes at oracle.com
Wed Oct 12 11:07:25 UTC 2016
On 12/10/2016 7:04 PM, Magnus Ihse Bursie wrote:
> On 2016-10-12 04:38, David Holmes wrote:
>> On 11/10/2016 7:41 PM, Erik Joelsson wrote:
>>> After the cleanup of C++ linking with the GCC toolchain. We missed
>>> updating one instance with the correct TOOLCHAIN configuration. This
>>> leads to build failures for arm ports with slowdebug. I have no idea why
>>> it only happens there, but correcting the TOOLCHAIN configuration (so
>>> that g++ is used to link instead of gcc) makes it build again.
>> Unexplained errors raise alarm bells for me. This particular reference
>> relates to C++ exception handling which raises questions:
>> - why only on this platform?
>> - why only in slowdebug?
>> - why only in this code? (which seems unrelated to exceptions)
>> I agree the fix is to use g++ instead of gcc for linking, assuming the
>> exception related code should actually be there.
> The alarm bells ringed for me too. :-) I actually started debugging this
> one, but Erik beat me to it. :) I did however conclude that this error
> occured due to static linking (without it, everything went fine) and if
> I explicitely specified -lstdc++ as well, I got a more informative
> error, telling me that the static version of libgcc was not found. I
> didn't go further, since Erik found the (correct) solution, but I assume
> that the devkit we use to build for the arm platforms are missing some
> bits, which was only needed for slowdebug builds.
Still too vague for me. What is special about this code?
>>> The build error looks like this:
>>> undefined reference to `__gxx_personality_v0'
>>> collect2: error: ld returned 1 exit status
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167479
>>> Webrev: http://cr.openjdk.java.net/~erikj/8167479/webrev.01/
More information about the build-dev