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, not lib/swift/linux/x86_64 and lib/swift/linux/aarch64:
Build the toolchain for linux x86_64 and install it.
Build the toolchain for linux aarch64 and install it to the same directory (build-script currently 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.
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.
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_64
andlib/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-script
currently 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.