Closed Bug 1270217 Opened 4 years ago Closed 2 years ago

Change MACOS_DEPLOYMENT_TARGET to 10.9

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(firefox62 fixed)

RESOLVED FIXED
mozilla62
Tracking Status
firefox62 --- fixed

People

(Reporter: gps, Assigned: jwatt)

References

Details

Attachments

(1 file)

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?
Flags: needinfo?(gps)
I have no clue. 302 Callek.
Flags: needinfo?(gps) → needinfo?(bugspam.Callek)
[root@bld-lion-r5-082.build.releng.scl3.mozilla.com ~]# 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)
Flags: needinfo?(bugspam.Callek)
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.)
No longer blocks: 1255589
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...
Flags: needinfo?(ted)
Flags: needinfo?(mh+mozilla)
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: → 1350036
302 ted
Flags: needinfo?(mh+mozilla)
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.
Flags: needinfo?(ted)
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.
Product: Core → Firefox Build System
Attached patch patchSplinter Review
Assignee: nobody → jwatt
Attachment #8982530 - Flags: review?(ted)
Still using 10.7 as the default has caused local builds to fail on Mac since bug 1465585 landed. Presumably this hasn't shown up on CI because we cross compile there.
Blocks: 1465585
Comment on attachment 8982530 [details] [diff] [review]
patch

Guess I should be making the request to the build peers alias nowadays.
Attachment #8982530 - Flags: review?(ted) → review?(core-build-config-reviews)
Comment on attachment 8982530 [details] [diff] [review]
patch

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

Thank you!  Please also modify old-configure.in's check for CoreMedia and build/gyp.mozbuild's values of mac_sdk_min and mac_deployment_target.

Please shout if those changes don't pass try for whatever reason.
Attachment #8982530 - Flags: review?(core-build-config-reviews) → review+
Pushed by jwatt@jwatt.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cbf0895981cd
Change the default MACOS_DEPLOYMENT_TARGET value to 10.9. r=froydnj
https://hg.mozilla.org/mozilla-central/rev/cbf0895981cd
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Since this landed bug 1405083 started to perma fail http://tinyurl.com/ydd64hyd
Flags: needinfo?(jwatt)
Thanks for your work looking after the tree, Cosmin. In this case we shouldn't back this out though, since it then breaks building locally for all devs on Mac. We should reland this and disable that test for now.
Flags: needinfo?(jwatt)
Pushed by jwatt@jwatt.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6b7ace4745e3
Change the default MACOS_DEPLOYMENT_TARGET value to 10.9. r=froydnj
Sorry about that Jonathan. Didn't see that coming. I will make sure to merge this around as soon as it has all the jobs done.
No worries. It was mentioned in comment 17, but isn't at all clear from the bug's summary. ;) Merging this around would be great, thank you!
makes you wonder what changes to the code this actually does for making a media webrtc mochitest fail.... must be some serious side effects there
https://hg.mozilla.org/mozilla-central/rev/6b7ace4745e3
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
(In reply to Jean-Yves Avenard [:jya] from comment #28)
> makes you wonder what changes to the code this actually does for making a
> media webrtc mochitest fail.... must be some serious side effects there

Targeting 10.9 means that our builds will use libc++ instead of libstdc++, which is a pretty big change. It's entirely possible that some code is hitting edge cases in the C++ standard library that differ between the two.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #30)
> (In reply to Jean-Yves Avenard [:jya] from comment #28)
> > makes you wonder what changes to the code this actually does for making a
> > media webrtc mochitest fail.... must be some serious side effects there
> 
> Targeting 10.9 means that our builds will use libc++ instead of libstdc++,
> which is a pretty big change. It's entirely possible that some code is
> hitting edge cases in the C++ standard library that differ between the two.

We should have been using libc++ since...I don't have the bug number, but it was a long time ago.  We definitely found some edge cases when we were making the switch, though.
Blocks: 1467582
No longer depends on: 1467582
I see this brought an installer size reduction on nightly. But I don't see this improvement on Beta, after the merge from June 19th. Could someone provide some insight here? I'm investigating some perf alerts.
No longer depends on: 1455364
No longer depends on: 1471363
No longer depends on: 1461871
No longer depends on: 1471504
You need to log in before you can comment on or make changes to this bug.