You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was just testing out cross-compilation of Swift packages that use macros, and it works fine with the latest 6.0 release for the first time:
> cd swift-syntax/Examples
> ~/swift-6.0.2-RELEASE-fedora39/usr/bin/swift sdk install ~/swift-6.0.2-RELEASE_static-linux-0.0.1.artifactbundle.tar.gz
Swift SDK bundle at `swift-6.0.2-RELEASE_static-linux-0.0.1.artifactbundle.tar.gz` is assumed to be an archive, unpacking...
Swift SDK bundle at `swift-6.0.2-RELEASE_static-linux-0.0.1.artifactbundle.tar.gz` successfully installed as swift-6.0.2-RELEASE_static-linux-0.0.1.artifactbundle.
> ~/swift-6.0.2-RELEASE-fedora39/usr/bin/swift build --swift-sdk aarch64-swift-linux-musl
Building for debugging...
Build complete! (1.04s)
However, if I try the same with the latest trunk 6.1 Musl or Android SDK bundles, it fails:
> ~/swift-6.0.2-RELEASE-fedora39/usr/bin/swift sdk remove swift-6.0.2-RELEASE_static-linux-0.0.1
Swift SDK bundle at path `/home/finagolfin/.swiftpm/swift-sdks/swift-6.0.2-RELEASE_static-linux-0.0.1.artifactbundle` was successfully removed from the file system.
> ~/swift-6.0.2-RELEASE-fedora39/usr/bin/swift package clean
> ~/swift-DEVELOPMENT-SNAPSHOT-2024-09-25-a-ubi9/usr/bin/swift sdk install ~/swift-DEVELOPMENT-SNAPSHOT-2024-09-25-a_static-linux-0.0.1.artifactbundle.tar.gz
Swift SDK bundle at `/home/finagolfin/swift-DEVELOPMENT-SNAPSHOT-2024-09-25-a_static-linux-0.0.1.artifactbundle.tar.gz` is assumed to be an archive, unpacking...
Swift SDK bundle at `/home/finagolfin/swift-DEVELOPMENT-SNAPSHOT-2024-09-25-a_static-linux-0.0.1.artifactbundle.tar.gz` successfully installed as swift-DEVELOPMENT-SNAPSHOT-2024-09-25-a_static-linux-0.0.1.artifactbundle.
> ~/swift-DEVELOPMENT-SNAPSHOT-2024-09-25-a-ubi9/usr/bin/swift build --swift-sdk aarch64-swift-linux-musl
Building for debugging...
error: link command failed with exit code 1 (use -v to see invocation)
clang: error: no such file or directory: '/home/finagolfin/.swiftpm/swift-sdks/swift-DEVELOPMENT-SNAPSHOT-2024-09-25-a_static-linux-0.0.1.artifactbundle/swift-DEVELOPMENT-SNAPSHOT-2024-09-25-a_static-linux-0.0.1/swift-linux-musl/musl-1.2.5.sdk/aarch64/usr/lib/swift/linux-static/aarch64/swiftrt.o'
If I pass in -Xswiftc -disallow-use-new-driver, it works again, so clearly a regression in this swift-driver, most likely related to #1667, which I argued against at the time.
@al45tair, can you confirm this regression and advise?
The text was updated successfully, but these errors were encountered:
I looked into this a bit more: the problem is still reproducible with the latest dev snapshots of the static Musl SDK for 6.1 and trunk, from Jan. 31 and Jan. 5 respectively. Turns out the 6.1 and trunk Android SDK bundles have a different error caused by another bug, which I will address separately.
This Musl SDK problem is actually different and larger, breaking building all executables with the static Musl SDK. As noted above, #1667 is the culprit, as it assumes that there is always a swiftrt.o in the shared Swift resource directory, which is not the case for the static Musl SDK. It's an easy fix, but I have a larger fix in mind to get rid of that swiftrt.o linking in this driver altogether, so will submit that instead.
finagolfin
changed the title
Swift 6.1 can not cross-compile the macro examples from the swift-syntax repository with the latest static linux Musl SDK or Android SDK bundles
Swift 6.1/6.2 can not cross-compile executables with the latest static linux Musl SDK bundle snapshots
Feb 16, 2025
I was just testing out cross-compilation of Swift packages that use macros, and it works fine with the latest 6.0 release for the first time:
However, if I try the same with the latest trunk 6.1 Musl or Android SDK bundles, it fails:
If I pass in
-Xswiftc -disallow-use-new-driver
, it works again, so clearly a regression in this swift-driver, most likely related to #1667, which I argued against at the time.@al45tair, can you confirm this regression and advise?
The text was updated successfully, but these errors were encountered: