1270217 - Change MACOS_DEPLOYMENT_TARGET to 10.9

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Gregory Szorc [:gps]]

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

Comment 1

[Benjamin Smedberg]

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.

Comment 2

[Mike Hommey [:glandium]]

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.

Comment 3

[Gregory Szorc [:gps]]

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

Comment 4

[Nathan Froyd [:froydnj]]

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

Comment 5

[Gregory Szorc [:gps]]

I have no clue. 302 Callek.

Comment 6

[Justin Wood (:Callek)]

[[e-mail] ~]# 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)

Comment 7

[Nathan Froyd [:froydnj]]

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

Comment 8

[(not currently active) Ted Mielczarek]

I think I created that tarball by logging in to a loaner and tarring it up, so that surprises me!

Comment 9

[(not currently active) Ted Mielczarek]

(but OS X also has system headers that live outside of the SDK, so things can get wonky.)

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 11

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.

Comment 12

[Mike Hommey [:glandium]]

302 ted

Comment 13

[(not currently active) Ted Mielczarek]

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.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

We could do this now, right?

Comment 15

[Gregory Szorc [:gps]]

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.

Comment 16

[Jonathan Watt [:jwatt]]

Attachment: patch

Comment 17

[Jonathan Watt [:jwatt]]

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.

Comment 18

[Jonathan Watt [:jwatt]]

Comment on attachment 8982530 [details] [diff] [review]
patch

Guess I should be making the request to the build peers alias nowadays.

Comment 19

[Nathan Froyd [:froydnj]]

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.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cbf0895981cd
Change the default MACOS_DEPLOYMENT_TARGET value to 10.9. r=froydnj

Comment 21

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/cbf0895981cd

Comment 22

[Cosmin Sabou [:CosminS]]

Since this landed bug 1405083 started to perma fail http://tinyurl.com/ydd64hyd

Comment 23

[Cosmin Sabou [:CosminS]]

Backed out for turning bug 1405083 into permafail. 

Treeherder push: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&fromchange=c78a67ef0566909b2f794c08aff4bc3bca9395f7&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=runnable&filter-resultStatus=success&filter-searchStr=15344eb1486fc27ed447354711261cdf9f4c2943&tochange=af6951f3fd418e6f363eaca1fb286658c627e57f&selectedJob=181593223

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=181593223&repo=mozilla-inbound&lineNumber=8460

Backout link: https://hg.mozilla.org/mozilla-central/rev/ad1249c83efb4c01bb86a1f4e4744af73d10acf8

Comment 24

[Jonathan Watt [: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.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6b7ace4745e3
Change the default MACOS_DEPLOYMENT_TARGET value to 10.9. r=froydnj

Comment 26

[Cosmin Sabou [:CosminS]]

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.

Comment 27

[Jonathan Watt [:jwatt]]

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!

Comment 28

[Jean-Yves Avenard [:jya]]

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

Comment 29

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/6b7ace4745e3

Comment 30

[(not currently active) Ted Mielczarek]

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

Comment 31

[Nathan Froyd [:froydnj]]

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

Comment 32

[Ionuț Goldan [:igoldan]]

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.