Closed Bug 1569728 Opened 4 months ago Closed 18 days ago

compile clang with GCC 7

Categories

(Firefox Build System :: General, task)

task
Not set

Tracking

(firefox72 fixed)

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: froydnj, Assigned: rjl)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

It's not enough to compile with -std=c++17, we have to make the libstdc++ headers that clang accesses the C++17 ones, i.e. the ones from GCC 7.

We need this change so that the newly-built clang will have
C++17-compatible libstdc++ headers installed. I believe this change
also means that the newly-built clang (and associated tools) links
against GCC 7's libstdc++, but we set RPATH or similar appropriately, so
there shouldn't be issues stemming from that.

Depends on: 1573820
Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d24ed38c76cd
manually instantiate some basic_string members for libstdc++ compat; r=glandium
https://hg.mozilla.org/integration/autoland/rev/a420714ee262
build clang toolchains with GCC 7; r=mshal

(In reply to Razvan Maries from comment #4)

Backed out for Android 4.0 API16+ GeckoView multi-arch fat AAR opt build bustages.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=263339050&resultStatus=success%2Cpending%2Crunning%2Ctestfailed%2Cbusted%2Cexception&classifiedState=unclassified&fromchange=3177490c6c0fba5c703a08d129ec55f3fd53bece&searchStr=android%2C4.0%2Capi16%2B%2Cgeckoview%2Cmulti-arch%2Cfat%2Caar%2Copt%2Cbuild-fat-aar-android-geckoview-fat-aar%2Fopt%2C%28bgv%29

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=263339050&repo=autoland&lineNumber=1924

Backout: https://hg.mozilla.org/integration/autoland/rev/bd28df9e69b9a47d547547b767d6761b3bde3258

Gah, I saw this on my try push too and foolishly ignored it.

nalexander, what's up with this build? Are we trying to pull in crashsymbols from multiple other android builds to do the repack (and that somehow failed?!), or something else? Not asking you to debug this, just asking on pointers to start with.

Flags: needinfo?(nfroyd) → needinfo?(nalexander)

(In reply to Nathan Froyd [:froydnj] from comment #5)

(In reply to Razvan Maries from comment #4)

Backed out for Android 4.0 API16+ GeckoView multi-arch fat AAR opt build bustages.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=263339050&resultStatus=success%2Cpending%2Crunning%2Ctestfailed%2Cbusted%2Cexception&classifiedState=unclassified&fromchange=3177490c6c0fba5c703a08d129ec55f3fd53bece&searchStr=android%2C4.0%2Capi16%2B%2Cgeckoview%2Cmulti-arch%2Cfat%2Caar%2Copt%2Cbuild-fat-aar-android-geckoview-fat-aar%2Fopt%2C%28bgv%29

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=263339050&repo=autoland&lineNumber=1924

Backout: https://hg.mozilla.org/integration/autoland/rev/bd28df9e69b9a47d547547b767d6761b3bde3258

Gah, I saw this on my try push too and foolishly ignored it.

nalexander, what's up with this build? Are we trying to pull in crashsymbols from multiple other android builds to do the repack (and that somehow failed?!), or something else? Not asking you to debug this, just asking on pointers to start with.

Yes, these fat AARs aggregate multiple builds. But they do so using specific fetches, so they're not trying to pull in multiple crashsymbols. However, they are API 16+ builds "turned into" fat AAR builds, so my guess is that something is wonky with the crash symbol flags. The fat AAR jobs themselves neither produce nor consume crash symbols, so you should have flexibility to disable (or enable) things to move past this specific issue, which appears to be missing crash symbols.

Flags: needinfo?(nalexander)

OK, so somehow the compiler change caused all of the Android builds to produce empty crashreporter-symbols files. o.O

Depends on: 1576751
Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/aaae16f5f29d
manually instantiate some basic_string members for libstdc++ compat; r=glandium
https://hg.mozilla.org/integration/autoland/rev/2f873da4b36e
build clang toolchains with GCC 7; r=mshal

(In reply to Razvan Maries from comment #10)

Backed out for causing Linux shippable opt build bustages.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=2f873da4b36e4404b7396bf4a1403d316b8ae450&selectedJob=264430506&searchStr=linux%2Cshippable%2Copt%2Cprofile-guided%2Coptimization%2Cbuilds%2Cbuild-linux-shippable%2Fopt%2Cbpgo%28b%29

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=264430506&repo=autoland&lineNumber=1482

Backout: https://hg.mozilla.org/integration/autoland/rev/8867e44d49793d8af6b514089cf4b5ebea446985

This isn't a problem specific to this push. You can see that comment 8 built shippable builds successfully, and:

https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=3852e7ad563312a2a7df51b921ca28b10391a902
https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=9781c938afa60cd1187eae6ade5b9588a33f551e

both built shippable builds successfully. It's not clear to me why:

https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=8774861d2dbdf17cb56b44ffa69f16412b723292

also failed.

I don't know how to retrigger the instrumented run and the PGO-use build to demonstrate that the problem is only intermittent; I tried doing so on my push, but none of the jobs--runs or builds--actually retriggered.

Flags: needinfo?(nfroyd)

mshal, would it be reasonable to implement something like bug 1560755 for the Linux three-stage build as well, since moving to a gcc7-compiled clang seems to cause intermittent corruption in the data produced by the pgo-run task? (Actually, does it make sense to just do it for all three-stage PGO builds?)

Flags: needinfo?(mshal)

(In reply to Nathan Froyd [:froydnj] from comment #12)

mshal, would it be reasonable to implement something like bug 1560755 for the Linux three-stage build as well, since moving to a gcc7-compiled clang seems to cause intermittent corruption in the data produced by the pgo-run task? (Actually, does it make sense to just do it for all three-stage PGO builds?)

The only real issue in moving it into the run task is that we need to have llvm-profdata available, so we'd have to add dependencies on the clang toolchain. So as long as we can rely on having access to native clangs for Mac & Windows long-term (eg: even if we end up cross-compiling everything from Linux), then we could just do it for all platforms.

Flags: needinfo?(mshal)
Depends on: 1580028

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:froydnj, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(nfroyd)
Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7cfa759188e0
manually instantiate some basic_string members for libstdc++ compat; r=glandium
https://hg.mozilla.org/integration/mozilla-inbound/rev/425af188aae9
build clang toolchains with GCC 7; r=mshal
Status: NEW → RESOLVED
Closed: 18 days ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
Port to comm-central to prevent bustage.
Assignee: nobody → rob
Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/716dfbe4f352
Port bug 1569728: Add linux64-gcc-7 toolchain. rs=bustage-fix DONTBUILD
Regressions: 1593223
Flags: needinfo?(nfroyd)
You need to log in before you can comment on or make changes to this bug.