fix(macos): haal het Metal-toolchainpad uit de koppelvlaggen #1946
No reviewers
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck!1946
Loading…
Reference in a new issue
No description provided.
Delete branch "build/metal-toolchain-zoekpad"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Wat dit oplost
Elke macOS-build opende met vier regels:
Sinds Xcode 26 komt de Metal-shadercompiler uit een los gedownload toolchain-cryptex. Zodra dat geladen is wijst
TOOLCHAIN_DIRtijdens het koppelen daarheen in plaats van naarXcodeDefault.xctoolchain— en daar staat alleen shadergereedschap (metal,metallib,air-*onderusr/bin), geenusr/lib. CocoaPods en Flutters eigen podhelper hangen daar wel het zoekpad naar de Swift-runtime aan op.Het is niet alleen ruis. Dezelfde waarde staat ook in
LD_RUNPATH_SEARCH_PATHS, en die bakt een dodeLC_RPATHín de gebouwde app:Dat koppelnummer (
abPHna) verschilt per Metal-asset, dus per machine en per Apple-update. Een pad dat per bouwmachine anders is hoort niet in een binary die we uitbrengen.De wijziging
Een
post_install-haak inmacos/Podfilehaalt dat ene pad weg uitLIBRARY_SEARCH_PATHSenLD_RUNPATH_SEARCH_PATHSvan alle gegenereerde xcconfigs. Wat overblijft is genoeg:/usr/lib/swiftblijft op beide regels staan, Xcodes eigen standaarden leveren de Swift-map van de SDK, en niets in het bundel hangt aan@rpath/libswift*(hele bundel doorzocht op Mach-O-bestanden, nul treffers).Twee dingen die tijdens het bouwen bleken:
"${TOOLCHAIN_DIR}"van CocoaPods en$(TOOLCHAIN_DIR)uit de podhelper — inPods-Runner.debug.xcconfigzelfs samen op één regel. Wie er één van pakt, laat de waarschuwing gewoon staan.DT_TOOLCHAIN_DIRkan niet. De eerste opzet leidde het pad daarheen om (dat wijst wél altijd naar Xcodes eigen toolchain). Xcode verbiedt die variabele hier expliciet en breekt de build af:error: DT_TOOLCHAIN_DIR cannot be used to evaluate LD_RUNPATH_SEARCH_PATHS, use TOOLCHAIN_DIR instead.SWIFT_STDLIB_PATHinPods-Runner-frameworks.shhoudt de oude schrijfwijze en blijft met opzet staan: die regel zit achterif [ "${XCODE_VERSION_MAJOR}" -lt 7 ]en wordt nooit uitgevoerd.De haak telt hardop hoeveel bestanden hij raakte (nu 30). Dat is er niet voor de sier: een haak die niets meer vindt ziet er precies zo uit als een haak die zijn werk deed, dus de nul is het signaal op de dag dat CocoaPods die regels anders gaat schrijven.
Tweede commit: een verkeerde bewering in BUILD.md
docs/BUILD.mdbeschreef de macOS-build alsof Swift Package Manager uitstaat en CocoaPods al het pluginwerk doet. Sinds #1733 is dat omgedraaid. Die alinea stond twee regels boven de tekst die deze PR toch al schreef, dus hij is meteen rechtgezet.Waarom hier geen regressietest bij zit
De wijziging zit in Ruby-code die CocoaPods uitvoert tijdens
pod install, op bestanden die niet in git staan en die alleen op macOS bestaan. Er is geen laag waarflutter testbij kan: een Dart-test zou hooguit de tekst van dePodfilekunnen aflezen, en dat toetst de bewering, niet het gedrag. Een poort intool/zou alleen kunnen aanslaan op een machine waarmacos/Podsal is uitgepakt — dus stil overslaan op de Linux-runner, en dat is precies het soort poort dat groen staat zonder iets te bewaken.Wat er wél is: het faalgedrag kondigt zichzelf aan. Verdwijnt de haak of verandert CocoaPods het formaat, dan staan die vier regels weer bij élke build in beeld — precies zoals ze deze PR hebben veroorzaakt.
Bewaker
Overgeslagen, expliciet. Deze wijziging raakt geen bestandsformaat, geen opslag, geen afhankelijkheid erbij, geen uitgaand verkeer en geen publieke belofte — het zijn koppelvlaggen voor de macOS-build en een build-notitie.
Getoetst
make checkgroenmake check-secretsgroen (gitleaks + trufflehog, 0 findings)make sastgroen (semgrep, 0 findings)ld: warning, 0 fouten, dode rpath wegld: warning, 0 fouten, rpaths schoonpod installgedraaid door Flutter zelf (Manifest.lockweggegooid): haak slaat aan, 0TOOLCHAIN_DIRover, build schoonEen eerdere ronde stond ten onrechte groen omdat de build niets te koppelen had en het oude product bleef staan. De cijfers hierboven komen uit builds die het product opnieuw hebben gemaakt.
Sinds Xcode 26 komt de Metal-shadercompiler uit een los gedownload toolchain-cryptex, en zodra dat geladen is wijst TOOLCHAIN_DIR tijdens het koppelen daarheen in plaats van naar XcodeDefault.xctoolchain. Daar staat alleen shadergereedschap en geen usr/lib, dus het zoekpad naar de Swift-runtime dat CocoaPods en Flutters podhelper daaraan ophangen bestaat niet. Elke build gaf vier regels ld: warning: search path '.../Metal.xctoolchain/usr/lib/swift/macosx' not found en dezelfde waarde in LD_RUNPATH_SEARCH_PATHS bakte een dode LC_RPATH in de gebouwde app, inclusief het koppelnummer van het cryptex — een pad dat per machine en per Apple-update verschilt, in een binary die we uitbrengen. Een post_install-haak haalt dat pad uit LIBRARY_SEARCH_PATHS en LD_RUNPATH_SEARCH_PATHS van alle gegenereerde xcconfigs, in beide schrijfwijzen: "${...}" van CocoaPods en $(...) uit de podhelper staan in Pods-Runner.debug.xcconfig samen op één regel. Getoetst met een koppeling die echt plaatsvond, in Debug en in Release: geen waarschuwingen, geen fouten, en otool -l laat de dode rpath niet meer zien. Niets in het bundel hangt aan @rpath/libswift*. Ook getoetst met een pod install die Flutter zelf startte, niet ik. Omleiden naar DT_TOOLCHAIN_DIR was de eerste opzet en gaat niet: Xcode verbiedt die variabele hier expliciet en breekt de build af. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>0485af1b7806896098810689609881d6cefd0a47d6cefd0a470f4936f2df0f4936f2df86613edad6