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)

Steve, can you look into this, this is blocking bumping the minimum version of GCC we require.

(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.)

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

(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.

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.

Oops, forgot I needed this patch too.

Comment on attachment 8729059 [details] [diff] [review] Use the tooltool gcc in automation rather than /tools Review of attachment 8729059 [details] [diff] [review]: ----------------------------------------------------------------- Heh.

https://hg.mozilla.org/integration/mozilla-inbound/rev/81c05ce091aa https://hg.mozilla.org/integration/mozilla-inbound/rev/fc29af76ded3

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.

https://hg.mozilla.org/mozilla-central/rev/81c05ce091aa https://hg.mozilla.org/mozilla-central/rev/fc29af76ded3