1247306 - update the OS X SDK that cross-mac builds use

Status: RESOLVED DUPLICATE of bug 1273981

(Firefox Build System :: General, defect)

Description

[Nathan Froyd [:froydnj]]

Over in bug 1246743, we want to use a static libc++.a for Mac builds, so we can stop depending on the system's old libstdc++.  We can't use the system's libc++ because it doesn't exist in 10.6 and we need to continue supporting 10.6.

Doing the builds works fine with a Mac host, because we use "whatever SDK comes with Xcode", which seems like sort of a dodgy strategy, but hey.  On a Linux host, however, we're using the 10.7 SDK, which has an older libc++.

Older clang (and therefore older libc++, such as the 10.7 SDK contains) had __atomic_* intrinsics that were similarly named to GCC's versions, but took different argument types.  Somewhere along the way, clang renamed their versions and implemented GCC's versions, with the result that newer clang can't use older headers.  We could work around this by liberal use of #define, but it seems better to upgrade the SDK in use to something closer to the Mac host builds in any case...

Comment 1

[Nathan Froyd [:froydnj]]

Ted, blame shows you landed the original patches; do you have objections to updating to something like 10.9, or 10.10, depending what's on the mac buildbots?

How did you generate the 10.7 SDK tarball?

Comment 2

[(not currently active) Ted Mielczarek]

Last I knew the Mac build machines were running 10.7. The newest version of Xcode that runs on 10.7 is Xcode 4.6, which AFAICT only includes the 10.8 SDK (this is pretty hard to actually find info on):
https://en.wikipedia.org/wiki/Xcode#4.x_series

Presumably we could just copy a newer SDK onto the machines and point the mozconfigs there.

It should be safe to use a newer SDK since we set MACOSX_DEPLOYMENT_TARGET=10.6:
https://dxr.mozilla.org/mozilla-central/rev/2dfb45d74f42d2a0010696f5fd47c7a7da94cedb/configure.in#451

...which should prevent us from using APIs that are unsupported on 10.6.

I generated the SDK tarball by simply taking a loaner Mac build machine, cd'ing to wherever the SDKs were (on my Mac running 10.10 it's /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/, but it might be /Developer/SDKs/ on older versions of Xcode), and running "tar cjf MacOSX10.7.sdk.tar.bz2 MacOSX10.7.sdk".

Comment 3

[Nathan Froyd [:froydnj]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2)
> I generated the SDK tarball by simply taking a loaner Mac build machine,
> cd'ing to wherever the SDKs were (on my Mac running 10.10 it's
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/
> Developer/SDKs/, but it might be /Developer/SDKs/ on older versions of
> Xcode), and running "tar cjf MacOSX10.7.sdk.tar.bz2 MacOSX10.7.sdk".

Hm, weird.  What does:

find /Applicates/Xcode.app/Contents/Developer -name algorithm

return on your Mac?  The newer SDKs don't appear to have appropriate C++ stdlib headers packaged with them.

Comment 4

[Nathan Froyd [:froydnj]]

Bleh, ni? for comment 3.

Comment 5

[Nathan Froyd [:froydnj]]

Ah, so we apparently got lucky; the 10.7 SDK packages up the libc++ headers, whereas the 10.8 SDK and following leave the libc++ headers in Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/.  Fabulous.  (Compare the contents of SDKs from https://github.com/phracker/MacOSX-SDKs/releases, for instance.)

I'm going to grovel through clang's search path logic to see if there's any rhyme or reason here.

Comment 6

[(not currently active) Ted Mielczarek]

Ignoring the iOS/TVOS stuff, I have:
/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1/algorithm
/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1/ext/algorithm
/Applications/Xcode.app/Contents/Developer//Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm

Comment 7

[(not currently active) Ted Mielczarek]

Do we still need this specifically, or is this just part of bug 1273981?