JDK-8291053 : GCC 6.3.0 build broken after HarfBuzz update
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 11.0.17,15.0.9,17.0.5,19.0.1,20
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2022-07-26
  • Updated: 2022-10-05
  • Resolved: 2022-07-28
Related Reports
Relates :  
JDK-8289853 - Update HarfBuzz to 4.4.1
Description
This might be a problem for backports, as update project might need to continue being buildable with older GCCs.

Reliably fails like this:

* For target support_native_java.desktop_libfontmanager_hb-draw.o:
In file included from src/java.desktop/share/native/libharfbuzz/hb.hh:473:0,
                 from src/java.desktop/share/native/libharfbuzz/hb-draw.cc:25:
src/java.desktop/share/native/libharfbuzz/hb-cplusplus.hh:170:13: error: specialization of 'template<class _Tp> struct std::hash' in different namespace [-fpermissive]
 struct std::hash<hb::shared_ptr<T>>
             ^~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/c++/6/bits/basic_string.h:5643:0,
                 from /usr/include/c++/6/string:52,
                 from /usr/include/c++/6/stdexcept:39,
                 from /usr/include/c++/6/array:39,
                 from /usr/include/c++/6/tuple:39,
                 from /usr/include/c++/6/functional:55,
                 from src/java.desktop/share/native/libharfbuzz/hb-cplusplus.hh:35,
                 from src/java.desktop/share/native/libharfbuzz/hb.hh:473,
                 from src/java.desktop/share/native/libharfbuzz/hb-draw.cc:25:
/usr/include/c++/6/bits/functional_hash.h:58:12: error:   from definition of 'template<class _Tp> struct std::hash' [-fpermissive]
   ... (rest of output omitted)


This might be a * For target support_native_java.desktop_libfontmanager_hb-draw.o:
In file included from src/java.desktop/share/native/libharfbuzz/hb.hh:473:0,
                 from src/java.desktop/share/native/libharfbuzz/hb-draw.cc:25:
src/java.desktop/share/native/libharfbuzz/hb-cplusplus.hh:170:13: error: specialization of 'template<class _Tp> struct std::hash' in different namespace [-fpermissive]
 struct std::hash<hb::shared_ptr<T>>
             ^~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/c++/6/bits/basic_string.h:5643:0,
                 from /usr/include/c++/6/string:52,
                 from /usr/include/c++/6/stdexcept:39,
                 from /usr/include/c++/6/array:39,
                 from /usr/include/c++/6/tuple:39,
                 from /usr/include/c++/6/functional:55,
                 from src/java.desktop/share/native/libharfbuzz/hb-cplusplus.hh:35,
                 from src/java.desktop/share/native/libharfbuzz/hb.hh:473,
                 from src/java.desktop/share/native/libharfbuzz/hb-draw.cc:25:
/usr/include/c++/6/bits/functional_hash.h:58:12: error:   from definition of 'template<class _Tp> struct std::hash' [-fpermissive]
   ... (rest of output omitted)
Comments
In-tree HarfBuzz was being used because there was no system HarfBuzz option when 11 launched. This continued to work past JDK-8282588 because gcc 4.8.5 - at least whatever version of it is in RHEL 7.9 - supports that flag: c++11 c++0x The 2011 ISO C++ standard plus amendments. Support for C++11 is still experimental, and may change in incompatible ways in future releases. The name c++0x is deprecated. Until recently, it seems HarfBuzz upstream were supporting this version - https://github.com/harfbuzz/harfbuzz/issues/1724 - and indeed had no intention of breaking GCC 6, as Aleksey pointed out - https://github.com/harfbuzz/harfbuzz/issues/3705 This intention to needlessly break builds may have been "well communicated", but that doesn't imply agreement. My position remains the same as I expressed here: https://mail.openjdk.org/pipermail/jdk-updates-dev/2022-January/011454.html What is the point of maintaining a stable JDK if you are going to backport breaking changes like this? There would be pushback if the same approach was tried with JDK changes. We don't backport e.g. enhancements to HotSpot to fix security bugs, we write fixes for the status quo in the supported version. This proposal was proceeding by us doing the very same thing for HarfBuzz; backporting a security fix to the affected version. Yes, we have now moved to using the system HarfBuzz for some builds of 11u and will have to try and use a newer compiler with others. But these are risky changes in a stable release that we would rather not make.
05-10-2022
[~andrew] I'm confused how could we possibly build with gcc 4.8.5 (and in-tree harfbuzz) since 11.0.16, given JDK-8282588. It was well communicated, fwiw. A reasonable way for the RHEL 7 platform would be to use system harfbuzz, which should be fine.
04-10-2022
Backporting this has also broken the build of OpenJDK on RHEL 7 with gcc 4.8.5. Aleksey's patch helps to fix the above failure, but there is another. Given that 11u did build with this version of gcc, this is a regression in what is supposed to be a stable update release.
04-10-2022
I adapted the Harfbuzz upstream patch for mainline, and it helps to build with GCC 6 and lower: https://cr.openjdk.java.net/~shade/8291053/8291053-gcc6-harfbuzz.patch
15-08-2022
No plans to do anything here. gcc 6.3 is old (2016) and harfbuzz is only in JDK 11 and later .. and later gcc versions are used there. Everyone seems to have already backported this anyway so I guess whatever they are using is later than 6.3. If some specific backport needs this then whoever owns that can take this up. I don't see any need.
28-07-2022
I see it was reported and fixed in HarfBuzz upstream: https://github.com/harfbuzz/harfbuzz/pull/3707 -- so maybe we would need a follow-up update to even newer HarfBuzz. The fix went into HarfBuzz 5.0.0 about three days ago. I wonder if 4.x.y release would even continue. From the release history, that seems unlikely.
26-07-2022