8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux #2982
Conversation
|
|
Webrevs
|
|
@prrace This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be: 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
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.
|
|
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. |
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.
|
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. |
|
/integrate |
openjdk
bot
added
integrated
|
@prrace Since your change was applied there have been 102 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 05fe06a. |
|
You mention that "too many systems have to old a version of harfbuzz". jdk/make/autoconf/lib-bundled.m4 Line 291 in cbffecc With undefined symbols also being left to runtime (hence why JDK-8272332 doesn't show up during build), it seems this could lead to sporadic runtime failures if OpenJDK is unknowingly built against a harfbuzz that is too old. |
|
Mailing list message from Philip Race on build-dev: You are right there's no check. One could be added by a motivated party .. -phi. On 9/15/21 12:47 PM, Andrew John Hughes wrote: |
|
@gnu-andrew Maybe I'm misunderstanding here, but if symbol lookup is done at runtime, then the failure would occur if the JDK is run on a system with a too old harfbuzz, not if it is built on it. So it seems you want runtime checks, not build-time checks, right? |
|
Yes, it would fail at runtime, perhaps in subtle ways if the issue is not a missing function but a difference in behaviour. In the scenario I'm considering, the build and runtime environments are effectively the same, as we're building packages for Fedora or RHEL on a specific version of that OS, which is then provided for that OS alone. We tend to use system libraries where possible as we know the library is going to be the same or newer than what we built against, and we benefit from fixes to the system library without rebuilding OpenJDK. Rather than relying on failures being found in an older environment at runtime, I'd like the build to check it is being built against is suitable. With that early build failure, we can then flip those builds to using the in-tree library. You do, however, make a good point that this check can be overridden at runtime if the build is run on a different system. So, if possible, it would be good to also have a runtime check if there is some clear entry point to add one. I'll try and look into a fix for both once the October security update cycle is out of the way. That's taking up most of my time right now. |
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
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/2982/head:pull/2982$ git checkout pull/2982