Platforms that don't have "fat" multi-architecture binaries should place their runtime libraries in an arch-specific directory #63645
Comments
finagolfin
added
bug
|
@buttaface Thank you for working on this! It does not have a fat library format for WASI, so the same rule can be applied as well as for linux. |
…-specific directories This is needed for all platforms that don't have multi-architecture libraries like Darwin. Resolves swiftlang#63645
…-specific directories This is needed for all platforms that don't have multi-architecture libraries like Darwin. Also, add the new architecture-specific rpath to the resulting swift-driver. This is the Swift translation of the Driver-specific changes of swiftlang/swift#63782. Resolves swiftlang/swift#63645
…-specific directories This is needed for all platforms that don't have multi-architecture libraries like Darwin. Resolves swiftlang#63645
…-specific directories This is needed for all platforms that don't have multi-architecture libraries like Darwin. Resolves swiftlang#63645
…-specific directories This is needed for all platforms that don't have multi-architecture libraries like Darwin. Also, add the new architecture-specific rpath to the resulting swift-driver. This is the Swift translation of the Driver-specific changes of swiftlang/swift#63782. Resolves swiftlang/swift#63645
…-specific directories This is needed for all platforms that don't have multi-architecture libraries like Darwin. Also, add the new architecture-specific rpath to the resulting swift-driver and make it possible to cross-compile this repo for non-Darwin platforms on Darwin. The driver changes are the Swift translation of the Driver-specific changes of swiftlang/swift#63782. Resolves swiftlang/swift#63645
finagolfin
added
toolchain
Linux
|
My linked pulls were rejected last year in favor of moving to full platform triples for the resource directory name instead, which nobody has yet implemented. |
AnthonyLatsis
added
platform support
unexpected behavior
finagolfin
added
standard library
|
@etcwilde, can we move forward with this? Unfortunately, swiftlang/swift-driver#1667 hacked this back into the swift-driver again, over my objections, so that the upcoming Swift 6.1 toolchain also looks in Compare what clang command the current 6.0.3 linux toolchain uses when linking with an to the slightly different clang flags with Swift 6.1: Specifically, the latter has a Evan, can you provide some direction here: have you changed your mind and now agree with putting the Swift runtime libraries for Unix and Windows in |
|
@finagolfin Clang runtime libs follow the new style with full target triples in the Windows toolchain. And swift-driver considers that now swiftlang/swift-driver@a9bf9bb Maybe it motivates progress for swift runtime libs? |
Yeah, I noticed that.
Actually implementing it in the toolchain is fairly easy, as you can see with the small changes in my linked pulls. The main difficulty is in deciding precisely what triple to use for each platform version. For example, Swift for Android currently does not use the API version in the module triples and we get away with it because Swift provides no API versioning for Android, #76671, but once we do, would we need to start versioning the Swift modules too? I don't know and that's before getting into FreeBSD and the static Musl linux SDK and all the other targets out there. |
No API versioning means that each toolchain version can only target one specific platform version right? (Or a range with stable ABI.) That has a lot of downsides, but it used to be ok in the past, because platforms either kept their ABIs stable('ish) or rebuilt the world for each release. If this is supposed to change, then yes, version everything that isn't ABI-stable = everything that doesn't get away with a fixed C interface = almost everything :) If Swift is serious about ABI resilience, then it might be able to avoid this versioning? I have no idea though to which extend that is reliable today. |
Replacing "each toolchain version" with "each SDK," as you well know we can ship multiple platform SDKs with a single toolchain, yes, that is mostly correct. There is an exception though in that if you pass in a versioned triple, the Swift compiler will pass that Android API version back to the C platform headers, so ClangImporter will give you the versioned C APIs you asked for. However, once you have to write Swift code that conditionally compiles or runs based on the Android API version, that is not possible, hence the linked issue.
Swift is only ABI-stable on Darwin platforms, nowhere else. However, this is a larger issue, as a platform can be ABI-stable and still add new APIs in later versions, so such versioning lets you use new APIs. Anyway, getting back to the broader issue of using platform triples to fix this issue, this is an internal compiler directory that should mostly only ever be accessed by the compiler directly, so we can always make mistakes and change this solution later. However, some thought should go into how we do it the first time, as there will always be some external scripts and other tooling that will break every time we make a change. |
Description
This is a long-standing issue where we cannot ship or link against the stdlib for different architectures in the same Swift resource directory, because the compiler places and adds a rpath to them in
lib/swift/linux, notlib/swift/linux/x86_64andlib/swift/linux/aarch64:@compnerd wrote about these issues when the problem was worse four years ago, and while some of that has since been fixed, this remaining issue of the runtime libraries location came up again last year.
Steps to reproduce
build-scriptcurrently does not support building two non-Darwin architectures at once, so it has to be run twice.).Expected behavior
Both architectures' runtime libraries install fine. Instead, the latter will overwrite the former.
Environment
Additional context
@compnerd fixed this for Windows already by installing the runtime libraries to arch-specific directories, and having the Swift driver look in those arch-specific directories instead when linking.
I've put together a similar pull for the Unix toolchain and it passes the compiler validation suite natively on Android, after updating some tests. I will submit it soon, once I get it to install the libraries properly when setting up the full toolchain, along with the needed modifications to the corelibs install.
@MaxDesiatov or @kateinoigakukun, what would you like to do for the wasm toolchain? I currently disable these changes in my pull for Darwin, which has fat libraries so doesn't need it, and WASI, because I don't know what that platform requires.
The text was updated successfully, but these errors were encountered: