Bug report
Bug description:
configure appends the device deployment-target flag to every iOS build, simulator included:
dnl Add the compiler flag for the iOS minimum supported OS version.
AS_CASE([$ac_sys_system],
[iOS], [
AS_VAR_APPEND([CFLAGS], [" -mios-version-min=${IPHONEOS_DEPLOYMENT_TARGET}"])
AS_VAR_APPEND([LDFLAGS], [" -mios-version-min=${IPHONEOS_DEPLOYMENT_TARGET}"])
],
)
-mios-version-min is an alias for -miphoneos-version-min, so it sets the platform to iOS device. Against the simulator SDK the linker then refuses everything it resolves there:
ld: building for 'iOS', but linking in dylib (.../iPhoneSimulator.sdk/usr/lib/libiconv.2.tbd) built for 'iOS-simulator'
configure already knows which one it is — _host_device is derived from the host triple at configure.ac:794 and is simulator here — but the flag ignores it.
This is masked when the compiler is invoked through the wrappers in Platforms/Apple/iOS/Resources/bin, because those pass --target=arm64-apple-ios-simulator, which pins the platform and makes the later flag inert. It bites anyone driving clang directly with -isysroot, which is the usual arrangement for a cross-compiling build system.
The failure is quiet rather than loud. Configuring main for the simulator this way still exits 0, but 17 conftest links fail in config.log and features are misdetected:
$ diff <(unpatched pyconfig.h) <(patched pyconfig.h)
< /* #undef HAVE_ICONV */
< /* #undef HAVE_LIBSQLITE3 */
< /* #undef HAVE_ZLIB_COPY */
< /* #undef PY_SQLITE_HAVE_SERIALIZE */
---
> #define HAVE_ICONV 1
> #define HAVE_LIBSQLITE3 1
> #define HAVE_ZLIB_COPY 1
> #define PY_SQLITE_HAVE_SERIALIZE 1
If any library ends up on LDFLAGS before the first compiler check, it fails outright instead, with configure: error: C compiler cannot create executables.
Reproducer, on macOS with Xcode:
SDK=$(xcrun --sdk iphonesimulator --show-sdk-path)
CC="$(xcrun --sdk iphonesimulator -f clang)" \
CPP="$CC -E" CFLAGS="-isysroot $SDK -arch arm64" LDFLAGS="-isysroot $SDK -arch arm64" \
../configure --host=aarch64-apple-ios12.0-simulator --build=$(../config.guess) \
--enable-framework --with-build-python=...
grep "^ld: building for" config.log
Selecting -mios-simulator-version-min when _host_device is simulator fixes it; the device build is unchanged. PR to follow.
CPython versions tested on:
CPython main
Operating systems tested on:
macOS
Linked PRs
Bug report
Bug description:
configureappends the device deployment-target flag to every iOS build, simulator included:-mios-version-minis an alias for-miphoneos-version-min, so it sets the platform to iOS device. Against the simulator SDK the linker then refuses everything it resolves there:configurealready knows which one it is —_host_deviceis derived from the host triple atconfigure.ac:794and issimulatorhere — but the flag ignores it.This is masked when the compiler is invoked through the wrappers in
Platforms/Apple/iOS/Resources/bin, because those pass--target=arm64-apple-ios-simulator, which pins the platform and makes the later flag inert. It bites anyone driving clang directly with-isysroot, which is the usual arrangement for a cross-compiling build system.The failure is quiet rather than loud. Configuring
mainfor the simulator this way still exits 0, but 17 conftest links fail inconfig.logand features are misdetected:If any library ends up on
LDFLAGSbefore the first compiler check, it fails outright instead, withconfigure: error: C compiler cannot create executables.Reproducer, on macOS with Xcode:
Selecting
-mios-simulator-version-minwhen_host_deviceissimulatorfixes it; the device build is unchanged. PR to follow.CPython versions tested on:
CPython main
Operating systems tested on:
macOS
Linked PRs