relates to:

• SR-1631 swift-integration-tests failing, unable to find libFoundation.so

Issue Description:

We need to audit and clean up our handling of dynamic library search paths in installable toolchains. This showed up while investigated SR-1631.

Some of the current problems/questions:

1. The swift compiler unconditionally embeds a DT_RUNPATH/DT_RPATH (depending on the linker in use) into libraries pointing at the current runtime library directory. I am not sure this is the right default behavior, and it is particularly wrong when the swift compiler is being run from a CI build location, not the install path.

2. Given #1, the installed libXCTest.so has a DT_RUNPATH to the buildbot directory embedded in it within the current toolchains we distribute.

3. We are using $ORIGIN in some places to allow for relocatable libraries, but we also have /usr/lib/swift/linux embedded in the Swift standard libraries. I am not sure this is really right to have both.

4. Some libraries (e.g., libFoundation.so) have no run path at all, and wouldn't be loadable (I think?) if they weren't pulled in by a process which had already loaded the necessary dependencies. It might be possible for this to cause problems in practice if libFoundation.so pulled in a libswift library that the main application didn't use, but I don't know if that can currently happen.

It would be good for someone who thoroughly understands the Linux dynamic linking landscape to audit what is currently being done and figure out the right answer for Swift with an eye towards supporting official distributions of the Swift 3.0 compiler and applications.