Per bsmedberg in bug 1269798 comment #4, it is a product requirement for Firefox 49+ to not run on OS X < 10.9. Per arr in bug 1269798 comment #1, Firefox automation has no intent to switch the existing Mac builders away from 10.7. Instead, they'll be transitioning to Linux cross-compile builds in several months time. So, we'll need to drop support for 10.7 and 10.8 by bumping MACOS_DEPLOYMENT_TARGET to 10.9 while still supporting building on OS X 10.7 in automation. This likely means employing some kind of cross compile configuration so host binaries needed during the build continue to work on 10.7 while target binaries only work on 10.9+.
An alternate solution is to add a runtime check when we launch Firefox so that it won't run under MacOS <10.9 but not actually change the build-time deployment target.
I guess the simplest thing to do would be to stop using the MACOSX_DEPLOYMENT_TARGET environment variable and use the -mmacosx-version-min compiler flag instead, ensuring it doesn't propagate to HOST_CFLAGS. That said, there's another dimension that is not written in comment 0: for that to work, we need a 10.9 SDK on the builders.
(In reply to Mike Hommey [:glandium] from comment #2) > That said, there's another dimension that is not written in comment 0: for > that to work, we need a 10.9 SDK on the builders. Presumably we could leverage tooltool to do this without any assistance from the server operators.
(In reply to Mike Hommey [:glandium] from comment #2) > That said, there's another dimension that is not written in comment 0: for > that to work, we need a 10.9 SDK on the builders. What do we actually have installed on the builders? e.g. for bug 1246743, I pushed a -stdlib=libc++ patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=726751fba647 The tests aren't in as of this writing, but you can see that the 10.7-using cross builds are busted due to compiler version mismatches (the <atomic> in the 10.7 sysroot expects certain prototypes for the __atomic_* family, while the compiler we use changed the prototype (!) and therefore needs a newer <atomic>) , while the native builds work just fine. What kind of sysroots/Xcode do we actually have on the native builders?
I have no clue. 302 Callek.
Flags: needinfo?(gps) → needinfo?(bugspam.Callek)
[firstname.lastname@example.org ~]# xcodebuild -showsdks Mac OS X SDKs: Mac OS X 10.6 -sdk macosx10.6 Mac OS X 10.7 -sdk macosx10.7 iOS SDKs: iOS 4.3 -sdk iphoneos4.3 iOS Simulator SDKs: Simulator - iOS 4.3 -sdk iphonesimulator4.3 (If theres another way to identify installed SDK's, let me know)
Hm, then our 10.7 SDK on the cross builders doesn't actually match what our 10.7 SDK on the native builders is using. :(
I think I created that tarball by logging in to a loaner and tarring it up, so that surprises me!
(but OS X also has system headers that live outside of the SDK, so things can get wonky.)
Where does this stand? Given https://blog.mozilla.org/futurereleases/2016/04/29/update-on-firefox-support-for-os-x/ , when will we be upgrading the SDK on the builders to something past 10.7? I'm trying to import code that uses a number of 10.8+ APIs, though mostly with version checks -- so the built code will run on 10.7, but needs to be built with a 10.8+ SDK. (The upstream uses SDK 10.11, but I haven't found anything added past 10.8 so far). I'll likely have to work around this somehow before this can be resolved (likely by ifdefing the 10.8+ parts and falling back to old APIs for all versions, or perhaps in some cases adding back in older code via ifdefs). Lots of pain...
When building Stylo locally, I've had to force MACOSX_DEPLOYMENT_TARGET=10.9, not sure if that's just my machine though. See bug 1350036 for more about that.
See Also: → bug 1350036
I think we're still stuck until we get our OS X builds migrated off of the existing 10.7 hardware. That work is currently blocked on bug 1338651, which we're actively investigating.
We could do this now, right?
It sounds like it. We're using the 10.11 SDK in CI. So the patch could perhaps be as easy as changing some string literals around.
You need to log in before you can comment on or make changes to this bug.