Restore -sdk Universally

[SDGGiesbrecht]

This is a simple revert of 42fc98ec3b5d10328875dc8c1499e4be6d7d2625 with the conflicts resolved.

It reapplies -sdk universally.
See discussion at #2617.

[aciidgh]

@swift-ci smoke test

[aciidgh]

@swift-ci smoke test linux

[aciidgh]

The linux failure seems related. The Swift compiler is looking in the wrong place for finding the swiftrt.o file. I think we need to point -sdk to the toolchain directory instead of .root here: https://github.com/apple/swift-package-manager/blob/master/Sources/Workspace/Destination.swift#L116

[SDGGiesbrecht]

Okay, well Linux seems pretty consistently certain that /usr/lib/swift/linux/x86_64/swiftrt.o doesn’t exist.

I downloaded the latest snapshot to check and that file does exist in the toolchain at that precise location relative to its root.

However, this line in the log seems to indicate that the toolchain isn’t installed at /:

${WORKSPACE}/latest_toolchain/${DOWNLOAD_DIR}-${PLATFORM}${MAJOR_VER}.${MIN_VER}/usr/bin/swiftc --version

The line that determined the host destination’s SDK to be .root (i.e. /) by default outside macOS seemed fishy to me before when I asked about it with regards to native Android compilation. Now I’m even more suspicious of it. Doesn’t that mean that a native toolchain will only ever work if it is installed at the root of the drive? Shouldn’t it be binDir.parentDirectory so that the toolchain points to itself? My thought is that without an explicit -sdk, swiftc was defaulting to its own toolchain, and that is what we should be doing too?

[finagolfin]

It's likely it used to work before the recent changes Saleem alludes to, but now will need to be adapted to the new swiftc expectations. Someone has to look into how those have changed, the first step will be where it looks for this swiftrt.o file.

For example, I noticed that SPM 5.1.4 was adding an rpath to both the lib/swift/android next to the compiler, ie the default resource directory path, and to sdkpath/usr/lib/swift because of this flag, ie /usr/lib/swift, so I disabled the latter for the Android package of Swift 5.1.4. That's just an unnecessary rpath, guess you have to look into the other implications for linux.

[SDGGiesbrecht]

@aciidb0mb3r, somehow your last comment escaped my notice and I was waiting for you to respond to something you had already pre‐empted. Sorry about that.

In the interim I did some experimenting, and pointing at the toolchain doesn’t work either; the compiler still cannot find everything it needs.

Instead, I’ll just send a pull request that merely adds || triple.isAndroid() to the existing condition. That should fix the only platform that is broken without meddling with any of the others.