swiftlang / swift-sdk-generator

Generate Swift SDKs for cross-compilation
Apache License 2.0
182 stars 15 forks source link

Switching to `swiftResourcesPath` broke building an SDK directly from Debian packages #141

Closed euanh closed 2 weeks ago

euanh commented 3 weeks ago

Change #139, which fixes building Swift 6.0 SDKs from containers, breaks building SDKs from Debian packages. I discovered this while trying to get the EndToEnd tests running on macOS, as discussed in #139! 😢

% swift build --swift-sdk 5.10.1-RELEASE_ubuntu_jammy_aarch64
<unknown>:0: error: unable to load standard library for target 'aarch64-unknown-linux-gnu'
<unknown>:0: error: unable to load standard library for target 'aarch64-unknown-linux-gnu'
error: fatalError

Currently we copy some SDK files into the .xctoolchain directory in the SDK bundle. Previously, the compiler found those files, but the swiftResourcesPath/swiftStaticResourcesPath configuration options causes it to look only in the .sdk directory, and the set of files we put there when building from Debian packages is not quite sufficient.

I don't think we should rely on adding files to the .xctoolchain directory. The static Linux SDK doesn't include a toolchain at all (it has a vestigial, empty .xctoolchain/bin), and a glib-based SDK built from a container can also build these additional files (this also suggests we could build glib SDKs without embedded toolchains, similar to the static Linux SDK).

It should also be possible to build an SDK from Debian-packages without putting files in .xctoolchain, but the files we unpack from .debs are much more limited than the files we copy from containers, so a bit more work is required.