8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

[prrace]

From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.

I ended up having to go this way because its is the least unsatisfactory solution.
I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
because too many systems have to old a version of harfbuzz.

This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10

There are couple of incidental fixes in here too

• "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
• harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
• I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Reviewers

• Sergey Bylokhov (@mrserb - Reviewer) ⚠️ Review applies to 29d3e4b
• Magnus Ihse Bursie (@magicus - Reviewer)
• Alexander Zvegintsev (@azvegint - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2982/head:pull/2982
$ git checkout pull/2982

[bridgekeeper]

👋 Welcome back prr! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@prrace The following labels will be automatically applied to this pull request:

• 2d
• build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 02: Full - Incremental (a92a146)
• 01: Full - Incremental (f668b32)
• 00: Full (29d3e4b)

[openjdk]

@prrace This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Reviewed-by: serb, ihse, azvegint

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 102 new commits pushed to the master branch:

• 422eba8: 8263536: Add @build tags to jpackage tests
• 0d2f87e: 8263562: Checking if proxy_klass_head is still lambda_proxy_is_available
• a67a679: 8263679: C1: Remove vtable call
• 11c8c78: 8248904: Add support to jpackage for the Mac App Store
• dc93138: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory
• e33bfb3: 8263450: Simplify LambdaForm.useCount
• 75ef6f5: 8263427: Shenandoah: Trigger weak-LRB even when heap is stable
• 4517d72: 8263612: Unused variables in C1 runtime
• 83a9a02: 8263509: LdapSchemaParser.readNextTag checks array length incorrectly
• 9c50b8e: 8263587: C2: JVMS not cloned when needs_clone_jvms() is true
• ... and 92 more: https://git.openjdk.java.net/jdk/compare/b7f0b3fc8b556b352fd7593ca674ab8e562c709a...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[magicus]

It feels a bit unfortunate that we had to end up this way. :-( I've read through the bug report and unnderstand that this might be the least bad way... but still.

Just thinking out loud, you don't think it would be better to build harfbuzz separately, but as a static library, that is then included in libfontmanager? The main win of doing that, I think, is the ability to have all the disabled warnings confined to the lower-quality upstream source. The resulting code would be the same. And from a build performance perspective I don't think any way of doing it matters.

[prrace]

Just thinking out loud, you don't think it would be better to build harfbuzz separately, but as a static library, that is then included in libfontmanager? The main win of doing that, I think, is the ability to have all the disabled warnings confined to the lower-quality upstream source. The resulting code would be the same. And from a build performance perspective I don't think any way of doing it matters.

I don't know that this would be worth such an effort. I've clearly separated the warnings we are disabling for HARFBUZZ and there's really not a lot of likelihood in my mind that these warnings will suddenly also start to apply to the small amount of JDK code that is in libfontmanager which is also much simpler code.

BTW I noticed we are still disabling all warnings for sunFont.c and after this is done I'll likely see if I can make a source code change to resolve that.

[magicus]

I was actually thinking that such a change would be simpler; more or less amounting to changing from LIBRARY to STATIC_LIBRARY. But if you feel that it is too much work, fine...

[prrace]

I was actually thinking that such a change would be simpler; more or less amounting to changing from LIBRARY to STATIC_LIBRARY. But if you feel that it is too much work, fine...

If you say so .. I have no idea what build changes would be needed. I'm just more familiar and comfortable with this and leaving aside the graal stuff I don't know if it is used like that anywhere by the main JDK build.

[prrace]

/integrate

[openjdk]

@prrace Since your change was applied there have been 102 commits pushed to the master branch:

• 422eba8: 8263536: Add @build tags to jpackage tests
• 0d2f87e: 8263562: Checking if proxy_klass_head is still lambda_proxy_is_available
• a67a679: 8263679: C1: Remove vtable call
• 11c8c78: 8248904: Add support to jpackage for the Mac App Store
• dc93138: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory
• e33bfb3: 8263450: Simplify LambdaForm.useCount
• 75ef6f5: 8263427: Shenandoah: Trigger weak-LRB even when heap is stable
• 4517d72: 8263612: Unused variables in C1 runtime
• 83a9a02: 8263509: LdapSchemaParser.readNextTag checks array length incorrectly
• 9c50b8e: 8263587: C2: JVMS not cloned when needs_clone_jvms() is true
• ... and 92 more: https://git.openjdk.java.net/jdk/compare/b7f0b3fc8b556b352fd7593ca674ab8e562c709a...master

Your commit was automatically rebased without conflicts.

Pushed as commit 05fe06a.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.