CC @belkadan

See, e.g., apple/swift-package-manager#459

I'm hesitant to mess with this because while the current situation is wrong, it's also useful.

• `swiftc foo.swift && foo` should continue to work.

• `swift build` should probably also work.

• If SwiftPM supports app targets, the correct path is the embedded one. (@executable_path/../Frameworks on macOS, @executable_path/Frameworks on other platforms)

• Eventually Apple platforms will have Swift libraries in the system somewhere, and then we don't need the ones you built with at all.

• We don't really have a distribution story for binaries built with swiftc or SwiftPM that aren't statically linked.

Rather than a -disable-stdlib-rpath flag or something, I'd lean more towards something like -stdlib-runtime-install-path, which would explicitly specify the rpath to use. An empty argument would mean no rpath. But I'm not sure if that's a good interface either, even if it's something usually specified by the Package.swift file.

One thing we can fix immediately is that we still add this rpath even with -static-stdlib. Ankit's going to write up a swiftc patch for that.

I actually just submitted a PR for not adding this when statically linking the standard library: #10381

As of that PR we no longer add the RPATH when statically linking the Swift stdlib.

If there's a prevailing idea here about how to solve the other issue I'd be happy to take a stab at it.

@belkadan When SwiftPM handles this itself, it can always directly pass the RPATH necessary, I'm not sure why swiftc doing it by default is the right interface (clang++ doesn't embed an RPATH to libc++, for example). Its rather annoying to have hard coded functionality with no way to disable it, so if we don't have an alternate proposal I would like some interface to disable it. I'm ok with your proposed `-stdlib-runtime-install-path` semantics, it is monotonically better than what we have now. Are you ok with going forward with that?

clang++ doesn't rpath to libc++ because libc++ has an absolute install path. swiftCore et al do not.

If you want to go with -stdlib-runtime-install-path, please bring it up on swift-dev so that other people can weigh in on the problem.

@dan-zheng added a flag for this a little more than a year ago and I have updated the CMake config of most of the toolchain to use it:

#27207

The help text for that flag is incorrect, as it is the default on macOS now, but not on linux and other platforms using the Unix driver (I don't know what Windows does for a rpath, maybe @compnerd could let us know). I think those are the right defaults for mac and unix, as macs now ship with Swift but most linux distros don't, and these new flags now allow the user to override those defaults.

We can probably close this now, once those remaining details are addressed.

I don't think Windows has an rpath, and the POSIX platforms now have sensible defaults and flags that let you opt out.