JDK-8215976 : OpenJDK fails to build with GCC 8.2 when the #include inside zip.cpp comes from a non-sysroot path
  • Type: Bug
  • Component: tools
  • Affected Version: 13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-01-01
  • Updated: 2019-03-19
  • Resolved: 2019-01-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13 Other
13 b05Fixed openjdk8u212Fixed
Related Reports
Relates :  
Description
On 28/11/2018 7:45 pm, Patrick Zhang wrote:
> When I build on the latest jdk/jdk code base with GCC 8.2 (configured sysroot as a customized path instead of default root directory of the linux system), it failed with error: "jdk.pack/share/native/common-unpack/zip.cpp:420:23: error: declaration of 'tm* gmtime_r(const time_t*, tm*)' has a different exception specifier".
> 
> The root cause is the /usr/include/time.h included in src/jdk.pack/share/native/common-unpack/zip.cpp is treated as a non-system header file, so the originally suppressed error concerning "mismatched exception specifiers" gets exposed now. As the macro __THROW is defined in sys/cdefs.h we could reuse it on the condition of (defined(__GNUC__) && defined(__THROW)). Could you please help review this simple patch and comment, thanks!
> 
> 
> diff -r 19b15ff2576b src/jdk.pack/share/native/common-unpack/zip.cpp
> 
> --- a/src/jdk.pack/share/native/common-unpack/zip.cpp    Tue Nov 27 21:20:16 2018 -0500
> 
> +++ b/src/jdk.pack/share/native/common-unpack/zip.cpp    Wed Nov 28 04:21:07 2018 -0500
> 
> @@ -417,7 +417,10 @@
> 
> }
> 
> 
> 
> #ifdef _REENTRANT // solaris
> 
> -extern "C" struct tm *gmtime_r(const time_t *, struct tm *);
> 
> +#if !(defined(__GNUC__) && defined(__THROW))
> 
> +#define __THROW
> 
> +#endif
> 
> +extern "C" struct tm *gmtime_r(const time_t *, struct tm *) __THROW;
> 
> #else
> 
> #define gmtime_r(t, s) gmtime(t)
> 
> #endif
> 
> Regards
> Patrick
> 
Comments
Cancelled my redundant request, aarch64-port/jdk8u-shenandoah/jdk pulls *everything* from jdk8u/jdk8u periodically.
19-03-2019

This case was originated by me, the issue was firstly found on an aarch64 platform with jdk8u+linux. Although it is a general problem at jdk/jdk, jdk8u, etc., my expectation is to have this fix in aarch64-port/jdk8u-shenandoah/jdk eventually. I was told the backport should go to jdk8u-dev before this, so it happened. Here is my recent request: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-March/007058.html I am not familiar with labels, perhaps it should be "jdk8u-aarch64-fix-request" mentioned by Andrew H. in another thread?
15-03-2019

This was already pushed to 8u at the end of January before the current labelling process was in place: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-January/008464.html Why the belated jdk8u-fix-request?
12-03-2019

Fix Request (8u) Trivial change, breaks build on important platforms.
12-03-2019

# HG changeset patch # User patrickz # Date 1546508379 -28800 # Thu Jan 03 17:39:39 2019 +0800 # Node ID 0a90eb1de8e4e6c87a6643072e00645d5dde9da2 # Parent 0b2574a2a6c7816e6a7b6fc05de18318a2b6e561 8215976: Fix gmtime_r declaration conflicts in zip.cpp with linux header files diff -r 0b2574a2a6c7 -r 0a90eb1de8e4 src/jdk.pack/share/native/common-unpack/zip.cpp --- a/src/jdk.pack/share/native/common-unpack/zip.cpp Tue Jan 15 08:03:30 2019 +0100 +++ b/src/jdk.pack/share/native/common-unpack/zip.cpp Thu Jan 03 17:39:39 2019 +0800 @@ -416,9 +416,11 @@ ((uLong)h << 11) | ((uLong)m << 5) | ((uLong)s >> 1); } -#ifdef _REENTRANT // solaris -extern "C" struct tm *gmtime_r(const time_t *, struct tm *); -#else +/* + * For thread-safe reasons, non-Windows platforms need gmtime_r + * while Windows can directly use gmtime that is already thread-safe. + */ +#ifdef _MSC_VER #define gmtime_r(t, s) gmtime(t) #endif /*
22-01-2019

[~rriggs] assigned to you as you are sponsoring.
22-01-2019

Discussion threads: http://mail.openjdk.java.net/pipermail/jdk-dev/2018-November/002263.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056969.html Final proposed patch: #ifdef _MSC_VER // Windows #define gmtime_r(t, s) gmtime(t) #endif
01-01-2019