[OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Magnus Ihse Bursie ihse at openjdk.java.net
Mon Mar 15 12:29:15 UTC 2021


On Sat, 13 Mar 2021 00:34:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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
>
> Marked as reviewed by serb (Reviewer).

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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2982


More information about the 2d-dev mailing list