Open finagolfin opened 3 months ago
You are right. We can't break ABI used by compiler. As stated in the commit https://github.com/swiftlang/swift/commit/098823606579ff342fd6b224b3e5d0ad75cf61b2#diff-4b74006b7c38d950627c4183690f1c6b5435d1b4da7a327fdf6ed9bcbb2cc33bR552-R555 , we intentionally did this to make macros work in Linux in the limited time frame.
I think the ideal solution is to do proper bootstrapping: 1) build a toolchain having RPATH to the runtime in the builder's toolchain 2) build a stdlib/runtime using the toolchain (1) 3) build a toolchain with the stdlib/runtime (2)
Until that, yeah, bundling the runtime from the builder toolchain might be a temporary solution. But I think we can defer that until an actual unavoidable ABI break occurs. And we should be able to detect that pretty obviously, like runtime crash.
Description
I was just building the toolchain natively on Android when this potential issue struck me. We build the Swift toolchain for linux on all the current CI branches with an older Swift 5.8.1 compiler, then set its runpath to the newer Swift stdlib it ships with:
This probably worked fine before when we bootstrapped the compiler against the new stdlib first, but now that we are only building the Swift compiler with the prebuilt 5.8.1 hosttools, this means the newer stdlib cannot change any of its ABI or behavior used by the compiler itself, or it will cause problems.
A potential solution is to start shipping the Swift 5.8.1 stdlib also with the toolchain, so the newer Swift stdlib is free to keep changing.
I have not observed any problems with this setup yet, but this move is fairly recent.
@etcwilde, @bnbarham, or @shahmishal, let me know what you think.
Reproduction
None
Expected behavior
See above
Environment
Swift 5.9 onwards
Additional information
No response