2025209 - Update macOS SDK to 26.4

Status: RESOLVED FIXED

(Firefox Build System :: Toolchains, defect)

Description

[Robert]

Steps to reproduce:

The current macOS SDK listed in https://github.com/mozilla-firefox/firefox/blob/7b74d86ca4ce65e82fdaa3095d2d39a26d3ac4f6/taskcluster/kinds/toolchain/macos-sdk.yml#L39 is no longer accessible, which makes system bootstrap fail silently.

You can reproduce by running curl -I -L https://swcdn.apple.com/content/downloads/60/22/089-71960-A_W8BL1RUJJ6/5zkyplomhk1cm7z6xja2ktgapnhhti6wwd/CLTools_macOSNMOS_SDK.pkg

Actual results:

The Apple CDN responds with a 403 error

$ curl -I -L https://swcdn.apple.com/content/downloads/60/22/089-71960-A_W8BL1RUJJ6/5zkyplomhk1cm7z6xja2ktgapnhhti6wwd/CLTools_macOSNMOS_SDK.pkg
HTTP/1.1 403 Forbidden
Server: Apple
Date: Sun, 22 Mar 2026 12:36:37 GMT
Content-Type: application/xml
Content-Length: 0
X-B3-TraceId: 1fcad3e7e9a6db92
Strict-Transport-Security: max-age=31536000; includeSubdomains
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-DLB-Upstream: 10.223.216.85:443
Via: 17.156.129.140, http/1.1 defra2-vp-vst-004.ts.apple.com (acdn/293.16398), https/1.1 defra2-vp-vfe-019.ts.apple.com (acdn/293.16398), https/1.1 uklon6-edge-lx-006.ts.apple.com (acdn/293.16398), https/1.1 uklon6-edge-bx-030.ts.apple.com (acdn/293.16398), http/1.1 uklon6-edge-bx-030.ts.apple.com (acdn/293.16398)
Age: 3
X-Cache: miss, miss, miss, miss, none
CDNUUID: 9e601ffc-2a60-4587-a9cb-2ec5c202384b-3494310327
Connection: keep-alive

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox Build System::Toolchains' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

https://treeherder.mozilla.org/jobs?repo=try&revision=0ce5c2dff3d71e28fa9c03acb2f867b4888db126

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Attachment: Bug 2025209 - Update macOS SDK to 26.4 for builds.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

The Try push in comment 2 had some real build failures. The test failures were all intermittents and not of concern.
https://treeherder.mozilla.org/logviewer?job_id=556025494&repo=try&task=B9IRT5p7QGOO-Hxzf7zLIQ.0&lineNumber=94971
https://treeherder.mozilla.org/logviewer?job_id=556025595&repo=try&task=ADaI8sx1TliV9t5gvqvabg.0&lineNumber=65600

Missing transitive includes

The 26.4 SDK no longer transitively provides <vector> via macOS system headers. Fixed by adding #include <vector> after the existing system includes.

js/src/builtin/TestingFunctions.cpp

Pre-existing bug exposed by the SDK update: *local = *localtm tried to dereference local which is a std::tm value, not a pointer. Fixed by changing *local = *localtm; → local = *localtm;

mozglue/baseprofiler/public/BaseProfilerMarkersPrerequisites.h

The 26.4 SDK annotated std::string(const char*) with [[nonnull]]. Default marker types have static constexpr const char* AllLabels = nullptr etc.; the compiler sees through the null check when the value is constexpr nullptr and warns/errors. Changed all if (T::X) guards to if constexpr (T::X != nullptr) so the dead null-passing branches are eliminated at compile time.

xpcom/io/nsLocalFileUnix.cpp: struct statfs incomplete type

The configure checks for statfs, statvfs, and related symbols all return "no" during cross-compilation from Linux, so none of HAVE_STATFS, HAVE_STATVFS, etc. are defined in mozilla-config.h. SDK 26.4's sys/mount.h still defines #define STATFS statfs as its own macro, but no longer fully defines struct statfs without _DARWIN_C_SOURCE, leaving it as an incomplete type.

Added a #elif defined(__APPLE__) && defined(__MACH__) fallback at the end of the existing STATFS macro chain in nsLocalFileUnix.cpp that defines STATFS as statvfs and F_BSIZE as f_frsize. sys/statvfs.h is already included via the HAVE_SYS_STATVFS_H guard (which is correctly detected) and defines struct statvfs fully without any feature-test-macro guards. On native macOS builds the configure checks succeed and HAVE_STATVFS is set, so the existing branch handles it; the new fallback only activates during cross-compilation.

With those issues fixed, builds are almost all working on Try now. Almost, but not quite, unfortunately. AArch64 shippable builds appear to be hitting linker failures with missing basic libSystem symbols (_thread_suspend, _time, _usleep, _vfprintf, _vm_copy, _write):
https://treeherder.mozilla.org/logviewer?job_id=556229886&repo=try&task=WGmtdL3VQsSE1H36p8-2mA.0&lineNumber=5832

Mike, I'm afraid I'm out of time until I get back from PTO. Can you please take a look? This looks like a more serious issue and I'm not entirely sure what the right solution is. The patch in Phabricator is up to date with as far as I've taken it. Thanks!

Comment 5

[Mike Hommey [:glandium]]

Attachment: Bug 2025209 - Upgrade toolchains to macOS SDK 26.4.

Comment 6

[Mike Hommey [:glandium]]

Attachment: Bug 2025209 - Upgrade toolchains to macOS SDK 26.4. r?#build

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/autoland/rev/c3f3f1d7a719
https://hg.mozilla.org/integration/autoland/rev/d35d16f5acbb

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/c3f3f1d7a719
https://hg.mozilla.org/mozilla-central/rev/d35d16f5acbb