feat(cider): what iTerm2 would take, measured rather than guessed master
The second north star, tried for the first time. It does not start: dyld: Library not loaded: /System/Library/Frameworks/CryptoKit.framework/... The interesting part is not that it fails, it is knowing exactly why without discovering it one dyld error at a time. scripts/macho-needs.py reads the load commands of a Mach-O and answers the whole question at once. For iTerm2 3.6.10, x86_64 slice: needs=89 present=63 in-bundle=10 missing=9 weak-missing=7 THE NINE FALL INTO EXACTLY TWO GROUPS. CryptoKit, QuickLookUI, ScreenCaptureKit, SwiftUI system frameworks, none in this tree libswift_Concurrency, libswiftSystem, Swift runtime, 5.5 and later libswiftSystem_Foundation, libswiftUniformTypeIdentifiers, libswiftWebKit THE SECOND GROUP IS ONE PIN BUMP. vendor/pins/swift is version.txt 5.2.2 and its build.sh extracts the dylibs straight out of an official swift.org release package. Every missing library there belongs to a later Swift, so moving the pin forward should supply all five with no new code. That is the tractable next step and it should come before anything else here. THE FIRST GROUP IS REAL WORK. SwiftUI is not a stub anyone writes in an afternoon, and a framework that loads while exporting nothing does not help: a two level namespace binds classes and data at load time, so it fails on the first symbol the application really uses. THE TOOL EARNS ITS PLACE TWICE. It resolves rpath and executable_path, because treating those as paths turns the ten frameworks iTerm2 ships INSIDE ITS OWN BUNDLE into missing ones and buries the four that matter. And it reads the MAGIC rather than asking whether the file exists: the forty four swift dylibs in the runtime tree are 131 byte git lfs POINTER FILES here and real Mach-O only in the nix pin, so an existence check reports a complete Swift runtime that dyld cannot load. It said not-macho=23 before the real ones were copied in from the pin, 0 after. On the bundle: the nixpkgs recipe points at the iTerm2 stable URL with a hash that no longer matches what the URL serves, so this one was fetched with its real hash. The version inside is still 3.6.10.