The Xcode "Build Fluxa Rust Core" run-script phase runs this script
with SDKROOT already exported for whichever platform Xcode is currently
building (e.g. iphonesimulator for the FluxaIos scheme). That ambient
value leaks into cc's default sysroot for every target this script
loops over, including unrelated ones, so linking the aarch64-apple-tvos
build picked up an iphonesimulator libiconv and failed with "building
for tvOS, but linking in dylib built for iOS-simulator". Override
SDKROOT per target using the same SDK path already resolved for
bindgen, so each cargo build gets a sysroot matching its own target.
build_rust_core never set IPHONEOS_DEPLOYMENT_TARGET/TVOS_DEPLOYMENT_TARGET,
so rustc fell back to its ancient default (iOS 10.0) when linking for
aarch64-apple-ios etc. That's too old for the rquickjs-sys objects, which
need ___chkstk_darwin support only available at a modern deployment
target, so linking fluxa_core failed with an undefined symbol.
build_streaming_engine already sets IPHONEOS_DEPLOYMENT_TARGET (default
18.5) for exactly this reason — mirror it here for both iOS and tvOS.
The \${arr[@]:-} default-value form avoids bash 3.2's unbound-variable
error on an empty array, but on macOS's stock bash it still expands to
a single empty-string word, so `env "" cargo build ...` tried to exec
an empty command name and failed with exit 127. Build the cargo
invocation as an array and only wrap it with `env` when bindgen_env
actually has entries, avoiding any [@] expansion of an empty array.
macOS's stock /bin/bash is 3.2, which raises "unbound variable" under
set -u when expanding an empty array via \${arr[@]} even with the [@]
syntax. build_rust_core hits this on the host-only build call (no
--target flag), where bindgen_env stays empty. Use the \${arr[@]:-}
default-value form, the standard bash 3.2-safe workaround.
rquickjs-sys has no prebuilt FFI bindings for iOS/tvOS targets, so
bindgen needs the matching SDK sysroot (iphoneos/iphonesimulator/
appletvos/appletvsimulator) and clang target triple per cross-compiled
target, or it silently uses the host's own headers and fails. Unverified
here — no Xcode/macOS available in this environment; needs confirming
on a real Mac before relying on it.
