{{ message }}
Repository navigation
fix(build): make macOS's libsystem/ with Xcode 16 too, as release builds do - #192
Draft
Kushalkhemka wants to merge 1 commit into
Draft
Kushalkhemka wants to merge 1 commit into
Kushalkhemka wants to merge 1 commit into
Conversation
…lds do darwin_libsystem.py read pi-bin's linked libraries and rpaths from dyld_info -dependents. Xcode 16's (GitHub's macOS 15 runners) prints no rpaths, so the script decided the runtime loads libSystem from /usr/lib and made no libsystem/: every macOS release since 1.0.3 shipped without it, and starts with about 17 M more instructions than a build made with a newer Xcode. The load commands now come from otool -l, and each import's name is the word before "(from libSystem)", which both dyld_info formats print. release.yml now stops when a macOS archive has no libsystem/.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A macOS release start costs about 17 M instructions more than a local build of the same source (M5:
pi --version70 vs 53 M,ready to type 170 vs 153 M,
pi -p222 vs 206 M on bolt-v1.0.5).The release archives have no
libsystem/besidepi-bin.scripts/lib/darwin_libsystem.py(#139) reads pi-bin's linkedlibraries and rpaths from
xcrun dyld_info -dependents. Xcode 16.4, which GitHub's macos-15 runners have, prints no rpathsection there, so the script decides the runtime is an older one and makes nothing. The release log says so:
The step is advice-only, so the build went on. Every macOS release since 1.0.3 (the first with #139) shipped without it. A
local build with a newer Xcode makes it, which is the whole local-vs-release gap.
Xcode 16's
dyld_info -importsalso prints no index column before each name, so the script's check (line.split()[1])would have read the wrong word once the first problem was fixed.
Change
darwin_libsystem.py: the load commands come fromotool -l(LC_LOAD_DYLIB,LC_RPATH); the import name is the wordbefore
(from libSystem), which both dyld_info formats print. The shim and its check are otherwise unchanged.release.yml: a macOS archive withoutlibsystem/libSystem.B.dylibstops the release, so this cannot silently come back.Nothing in Pi or the engine changes; the executables are the same, only
libsystem/(six 16 KB files) is added beside them.Evidence
macOS release builds on GitHub's macos-15 runner, as release.yml makes them (fetch-runtime bolt-v1.0.5, prepare-pi.sh,
package-release.sh), scratch run 40526577133:
libsystem: pi-bin loads libSystem from /usr/lib (an older runtime): none made(as the release)libsystem: 483 imports bind to the same addresses through it; check-macos-floor passes for the new dylibs(macOS 13.0); tests/pi/run.sh passes.
M5, instructions, interleaved medians (ready.py), the CI-built archives against the bolt-v1.0.5 archive and a copy of it:
RESULTS_TABLE
Sameness (CI-built fix vs bolt-v1.0.5, default and -jit): SAMENESS
Linux and Windows have no such gap: a build made on a runner with build-pi.sh / build-pi.ps1 runs as the bolt-v1.0.5
archive does (Linux x86-64: startup 7 / 7 ms CPU,
pi -p43 / 44, interactive 136 / 137, release copy 8 / 43 / 138;-jit within 3%. Windows:
--version17 / 17 ms,pi -p79 / 80, copies 16-17 / 80-81). Their builds have noadvice-only step like this one, and the release logs show no skipped step.