Specifying a SDK with -sdk /path
has the driver looking in a wrong resource directory path too on non-Darwin
#63416
Labels
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
compiler
The Swift compiler itself
legacy driver
Area → compiler: the integrated C++ legacy driver. Succeeded by the swift-driver project
Linux
Platform: Linux
swift 5.9
unexpected behavior
Bug: Unexpected behavior or incorrect output
Description
I've started looking into moving the runtime libraries into the architecture-specific directory on Unix platforms, and I noticed this oddity in the paths it looks for libraries and the rpaths it applies. If I compile a simple executable on linux, here are the paths generated:
Note that it only links against
-L /home/butta/swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift/linux
and adds a rpath for that one directory.Steps to reproduce
However, if I make explicit the SDK it's using,
now it's also looking in
-L /usr/lib/swift
and adding that rpath too, when I only want it to look in the local toolchain. This happens even if I specify the resource directory with-resource-dir /home/butta/swift-5.7.3-RELEASE-ubuntu20.04/usr/lib/swift
in addition to the SDK.Expected behavior
While the default behavior is not to specify the SDK or resource directory and assume they are at
/
and/usr/lib/swift
, one often specifies both when cross-compiling, ie a C cross-compilation sysroot is the SDK and the resource directory is a separate Swift directory. In that case, the compiler looks in a separate extra directory in the C sysroot where there are no Swift files. While this may not cause problems because that directory either doesn't exist or has no libraries, we should clean that up. @colemancda, could you confirm that you see this issue with your linux cross-compilation sysroots?Environment
Additional context
This is because of this block added by @beccadax in 2019, which was most likely a mistake as it doesn't add the platform name, ie it adds
/usr/lib/swift
not the correct/usr/lib/swift/linux
. It was most likely incorrectly added to get the resource directory from the SDK, but since it didn't work, @compnerd soon after added a working method in #25990.I'd like to submit a pull to remove or disable that last block from
getRuntimeLibraryPaths()
, but I'm unsure if other platforms rely on it, ie/path/to/sdk/usr/lib/swift
. Linux definitely doesn't, putting the runtime libraries in/path/to/sdk/usr/lib/swift/linux
instead, but I've never used the non-Unix toolchains.Could @beccadax, @compnerd, and @MaxDesiatov let me know if you need this block for Darwin, Windows, or Wasm, and I'll submit a pull to disable it for the platforms where it's unused?
The text was updated successfully, but these errors were encountered: