Closed Bug 1150338 Opened 5 years ago Closed 4 years ago

"autospider" builds (e.g. compaction builds) are using /tools/gcc-4.7.2-0moz1/bin/gcc

Categories

(Core :: JavaScript Engine, defect)

All
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 --- fixed

People

(Reporter: glandium, Assigned: sfink)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Those builds should be using the same compiler as browser builds, which use tooltool to get their compiler.
(and btw, browser builds are currently using 4.8.3, where those builds are using 4.7.2)
Blocks: 1150618
Steve, can you look into this, this is blocking bumping the minimum version of GCC we require.
Blocks: gcc-4.8
Flags: needinfo?(sphink)
(In reply to Mike Hommey [:glandium] from comment #2)
> Steve, can you look into this, this is blocking bumping the minimum version
> of GCC we require.

Uh, yes, especially since I thought I'd already fixed this in bug 1146520, but it seems like either I never landed it or it was backed out.

Anyway, I would very much like to get these things pulling from tooltool. (Actually, I'd rather switch to the taskcluster versions of all of these, and they already pull from tooltool. But I have a little more work to go before I can do that.)
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(sphink)
Resolution: --- → DUPLICATE
Duplicate of bug: 1146520
Flags: needinfo?(sphink)
(In reply to Mike Hommey [:glandium] from comment #4)
> If what you landed today in bug 1146520 is supposed to make those builds
> pull from tooltool, it failed doing so:
> http://archive.mozilla.org/pub/spidermonkey/try-builds/mh@glandium.org-
> 0d77a7db77477a59bff99e9091a7e83dbf3ebec0/try-linux-debug/try_linux-
> debug_spidermonkey-arm-sim-bm79-try1-build952.txt.gz

I landed an ancient patch that makes them pull from tooltool, and it looks like it worked for most of the builds but not the arm-sim build. But the tooltool-pulled bits are not getting used; that will require further changes within the gecko tree. I wasn't sure if it would or not, but because that stuff is in a separate repo I just wanted to get it landed and in to try working with it. (So yes, debugging/developing in production.)

But I'm confused about how you got that failure. Those jobs are not failing on mozilla-inbound, nor are they failing for other people's try pushes. And the autospider.sh script looks to be the same between your broken build and someone else's working one.

Yours: http://archive.mozilla.org/pub/spidermonkey/try-builds/mh@glandium.org-0d77a7db77477a59bff99e9091a7e83dbf3ebec0/try-linux-debug/try_linux-debug_spidermonkey-arm-sim-bm79-try1-build952.txt.gz

Working: http://archive.mozilla.org/pub/spidermonkey/try-builds/tmielczarek@mozilla.com-e94afcfb33336cf38bf9759e500d1803efcf3dfa/try-linux-debug/try_linux-debug_spidermonkey-arm-sim-bm79-try1-build957.txt.gz

Working: http://archive.mozilla.org/pub/spidermonkey/tinderbox-builds/mozilla-inbound-linux-debug/mozilla-inbound_linux-debug_spidermonkey-arm-sim-bm91-build1-build44.txt.gz

The difference is that in your build, somehow GCCDIR was already set before autospider.sh was called. The "working" builds see that it's unset and fall back on /tools/gcc-4.7.2-0moz1 (so even the non-arm builds, which successfully pull down the newer gcc, are not yet using it.) In your build, it seems like it was already set, but nothing in the log or that I can see in the tree should do that. Is that on top of other patches that could affect that?

Anyway, things are definitely not yet in the final state. And unfortunately, it looks like the arm-sim build will require more out-of-tree changes to get the right releng.manifest.
Flags: needinfo?(sphink)
Sorry, terrence, another review to make your eyes glaze over. You're not really the right review for the .yml bits, but they're pretty minor.

The success of this patch depends on spidermonkey.sh doing the right thing. I've landed changes in the build-tools repo that are what I hope is enough to do that, but I have not yet gotten a 100% successful try run out of it. Hopefully, my most recent will be good (it includes some other goop, though): https://treeherder.mozilla.org/#/jobs?repo=try&revision=93cbec3ce8f2

That only includes the problematic linux(32) platform. https://treeherder.mozilla.org/#/jobs?repo=try&revision=7034a92f6534 has everything else working.
Attachment #8729048 - Flags: review?(terrence)
Assignee: nobody → sphink
Attachment #8729048 - Flags: review?(terrence) → review+
Oops, forgot I needed this patch too.
Attachment #8729059 - Flags: review?(terrence)
Comment on attachment 8729059 [details] [diff] [review]
Use the tooltool gcc in automation rather than /tools

Review of attachment 8729059 [details] [diff] [review]:
-----------------------------------------------------------------

Heh.
Attachment #8729059 - Flags: review?(terrence) → review+
Un-duping, since that other bug is really about adding OSX builds, and only happens to have some functionality needed by this bug.

But this one is now fixed. I'll let the automation close it.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
https://hg.mozilla.org/mozilla-central/rev/81c05ce091aa
https://hg.mozilla.org/mozilla-central/rev/fc29af76ded3
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.