https://tbpl.mozilla.org/?tree=Elm&rev=935ab6167c6d The only change between last green and this red that touches dom/plugins/ipc is bug 1042878.
Testing a backout of bug 1042878: https://tbpl.mozilla.org/?tree=Try&rev=3a328d842b3d
With a proper backout: https://tbpl.mozilla.org/?tree=Try&rev=a67816412268
Created attachment 8466259 [details] [diff] [review] move MOZ_GTK*_CFLAGS hacking from config.mk to configure.in This move ensures that other makefile variables that reference MOZ_GTK*_CFLAGS, e.g. TK_CFLAGS, will always have a consistent view of MOZ_GTK*_CFLAGS. (This happens because, even though TK_CFLAGS is literally $(MOZ_GTK_CFLAGS), we weren't twiddling with MOZ_GTK_CFLAGS until *after* backend.mk got included. Which caused problems when we moved things from: OS_CXXFLAGS += $(TK_CFLAGS) in Makefile.in to: CXXFLAGS += CONFIG['TK_CFLAGS'] in moz.build, as things got evaluated in a different order. I think.)
Attachment #8466259 - Flags: review?(mshal)
GTK+3 try run: https://tbpl.mozilla.org/?tree=Try&rev=ad925183f376 Builds fine for me locally, with GTK+2.
Attachment #8466259 - Flags: review?(mshal) → review+
(In reply to Nathan Froyd (:froydnj) from comment #3) > Which caused problems when we moved things from: > > OS_CXXFLAGS += $(TK_CFLAGS) > > in Makefile.in to: > > CXXFLAGS += CONFIG['TK_CFLAGS'] > > in moz.build, as things got evaluated in a different order. I think.) It's actually simpler than that. It's because some moz.builds have CXXFLAGS += CONFIG['MOZ_GTK2_CFLAGS'] during the gtk3 build.
Mike had said something about landing this directly on central, but that was Friday evening...I figure things will be merged to central or close to it by the time he wakes up: https://hg.mozilla.org/integration/mozilla-inbound/rev/ca2ba3cafed7
Assignee: nobody → nfroyd
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.