Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8266545: 8261169 broke Harfbuzz build with gcc 7 and 8 #3873

Closed

Conversation

tstuefe
Copy link
Member

@tstuefe tstuefe commented May 5, 2021

Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS issue.

I fixed the issue in the harfbuzz sources, but I am not sure of the policy here. Do we modify the harfbuzz sources or leave them untouched? Advice is welcome.

The patch fixes linux x64 fastdebug and opt build for me.


Progress

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

Issue

  • JDK-8266545: 8261169 broke Harfbuzz build with gcc 7 and 8

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3873/head:pull/3873
$ git checkout pull/3873

Update a local copy of the PR:
$ git checkout pull/3873
$ git pull https://git.openjdk.java.net/jdk pull/3873/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3873

View PR using the GUI difftool:
$ git pr show -t 3873

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3873.diff

@tstuefe tstuefe marked this pull request as ready for review May 5, 2021 07:54
@bridgekeeper
Copy link

bridgekeeper bot commented May 5, 2021

👋 Welcome back stuefe! 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 openjdk bot added the rfr Pull request is ready for review label May 5, 2021
@openjdk
Copy link

openjdk bot commented May 5, 2021

@tstuefe The following label will be automatically applied to this pull request:

  • 2d

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

@openjdk openjdk bot added the 2d client-libs-dev@openjdk.org label May 5, 2021
@mlbridge
Copy link

mlbridge bot commented May 5, 2021

Webrevs

@tstuefe
Copy link
Member Author

tstuefe commented May 5, 2021

/cc build-dev

@openjdk openjdk bot added the build build-dev@openjdk.org label May 5, 2021
@openjdk
Copy link

openjdk bot commented May 5, 2021

@tstuefe
The build label was successfully added.

Copy link
Member

@MBaesken MBaesken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks Thomas !

@openjdk
Copy link

openjdk bot commented May 5, 2021

@tstuefe 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:

8266545: 8261169 broke Harfbuzz build with gcc 7 and 8

Reviewed-by: mbaesken, rrich

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 19 new commits pushed to the master branch:

  • 22ca62c: 8266542: Remove broken -XX:-UseLoopSafepoints flag
  • 7835cdb: 8265915: adjust state_unloading_cycle compuation order in nmethod::is_unloading
  • 20ad428: 8180568: Refactor javax/crypto shell tests to plain java tests
  • 138d573: 8262392: Update Mesa 3-D Headers to version 21.0.3
  • 9de62a4: 8266505: Cleanup LibraryCallKit::make_unsafe_address()
  • 1885c83: 8266504: Remove leftovers from BarrierSetAssemblerC1
  • 6018336: 8259316: [REDO] C1/C2 compiler support for blackholes
  • f07bb2f: 8250766: javadoc adds redundant spaces when @see program element is wrapped
  • 61bb6ec: 8266453: Shenandoah: Disable write protections before patching nmethod in nmethod_barrier on MacOSX/AArch64
  • a05e8e2: 8266497: Remove unnecessary EMCP liveness indication
  • ... and 9 more: https://git.openjdk.java.net/jdk/compare/82768d9a31edcfe5b27e75d681d3592c8f4a2ece...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.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label May 5, 2021
@tstuefe
Copy link
Member Author

tstuefe commented May 6, 2021

Ping. Anyone?

@tstuefe
Copy link
Member Author

tstuefe commented May 6, 2021

I issued an upstream PR: harfbuzz/harfbuzz#2973

Copy link
Member

@shipilev shipilev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, current jdk master builds fine with gcc 9.3.0. It fails with gcc 6.3.0 to me.

I am unaware of the policy of changing the Harfbuzz sources too. If we are changing the Harfbuzz sources, I prefer the multi-line form you did in Harfbuzz PR, though: harfbuzz/harfbuzz#2973 -- it would also simplify the merge.

But there is an alternative, disable the warning and then wait for Harfbuzz fix to drop:

diff --git a/make/modules/java.desktop/lib/Awt2dLibraries.gmk b/make/modules/java.desktop/lib/Awt2dLibraries.gmk
index ff5fa00c720..627aa51ebdf 100644
--- a/make/modules/java.desktop/lib/Awt2dLibraries.gmk
+++ b/make/modules/java.desktop/lib/Awt2dLibraries.gmk
@@ -465,7 +465,7 @@ else
 
    HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing
    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \
-        maybe-uninitialized class-memaccess unused-result
+        maybe-uninitialized class-memaccess unused-result extra
    HARFBUZZ_DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \
         tautological-constant-out-of-range-compare int-to-pointer-cast \
         undef missing-field-initializers range-loop-analysis \

@tstuefe
Copy link
Member Author

tstuefe commented May 6, 2021

FWIW, current jdk master builds fine with gcc 9.3.0. It fails with gcc 6.3.0 to me.

I am unaware of the policy of changing the Harfbuzz sources too. If we are changing the Harfbuzz sources, I prefer the multi-line form you did in Harfbuzz PR, though: harfbuzz/harfbuzz#2973 -- it would also simplify the merge.

But there is an alternative, disable the warning and then wait for Harfbuzz fix to drop:

diff --git a/make/modules/java.desktop/lib/Awt2dLibraries.gmk b/make/modules/java.desktop/lib/Awt2dLibraries.gmk
index ff5fa00c720..627aa51ebdf 100644
--- a/make/modules/java.desktop/lib/Awt2dLibraries.gmk
+++ b/make/modules/java.desktop/lib/Awt2dLibraries.gmk
@@ -465,7 +465,7 @@ else
 
    HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing
    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \
-        maybe-uninitialized class-memaccess unused-result
+        maybe-uninitialized class-memaccess unused-result extra
    HARFBUZZ_DISABLED_WARNINGS_clang := unused-value incompatible-pointer-types \
         tautological-constant-out-of-range-compare int-to-pointer-cast \
         undef missing-field-initializers range-loop-analysis \

You are right, that is much better. Why did this not occur to me. I will do this.

@tstuefe
Copy link
Member Author

tstuefe commented May 6, 2021

I changed the fix according to @shipilev suggestion. This avoids all the hassle of changing downstream HB sources.

@shipilev can we consider this as trivial?

Copy link
Member

@reinrich reinrich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks!
Personally I'm building with gcc 9. I've test your fix successfully with gcc 7.5.

Cheers, Richard.

@tstuefe
Copy link
Member Author

tstuefe commented May 6, 2021

Looks good to me, thanks!
Personally I'm building with gcc 9. I've test your fix successfully with gcc 7.5.

Cheers, Richard.

Thanks Richard! I tested the build on Debian with gcc 7 and gcc 9, it worked.

Since I now have enough reviews, I'' push after the GHA are through

@tstuefe
Copy link
Member Author

tstuefe commented May 6, 2021

/integrate

@openjdk openjdk bot closed this May 6, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 6, 2021
@openjdk
Copy link

openjdk bot commented May 6, 2021

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

  • 2dd5667: 8266018: Shenandoah: fix an incorrect assert
  • 22ca62c: 8266542: Remove broken -XX:-UseLoopSafepoints flag
  • 7835cdb: 8265915: adjust state_unloading_cycle compuation order in nmethod::is_unloading
  • 20ad428: 8180568: Refactor javax/crypto shell tests to plain java tests
  • 138d573: 8262392: Update Mesa 3-D Headers to version 21.0.3
  • 9de62a4: 8266505: Cleanup LibraryCallKit::make_unsafe_address()
  • 1885c83: 8266504: Remove leftovers from BarrierSetAssemblerC1
  • 6018336: 8259316: [REDO] C1/C2 compiler support for blackholes
  • f07bb2f: 8250766: javadoc adds redundant spaces when @see program element is wrapped
  • 61bb6ec: 8266453: Shenandoah: Disable write protections before patching nmethod in nmethod_barrier on MacOSX/AArch64
  • ... and 10 more: https://git.openjdk.java.net/jdk/compare/82768d9a31edcfe5b27e75d681d3592c8f4a2ece...master

Your commit was automatically rebased without conflicts.

Pushed as commit a86ee9b.

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

@prrace
Copy link
Contributor

prrace commented May 6, 2021

The policy is to do what you ended up doing. We (almost) never modify 3rd party sources in such cases.
About the only case is if a fix has already been pushed upstream then we might copy that fix.
You did the right thing notifying upstream but still best to just disable this warning for now.

@tstuefe
Copy link
Member Author

tstuefe commented May 6, 2021

Thanks @prrace. I agree this is the simplest way. Good that Aleksey had this idea.

@tstuefe tstuefe deleted the JDK-8266545-harfbuzz-build-broken branch May 7, 2021 08:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2d client-libs-dev@openjdk.org build build-dev@openjdk.org integrated Pull request has been integrated
5 participants