@compnerd can you explain why this is required? I wouldn't have expected the Swift change to change behavior for clients?

I wouldn't expect that to change either. Interestingly enough, I can't seem to get the binary to run with BFD nor gold unless the LD_LIBRARY_PATH is set.

It seems that we are not setting the RPATH for libXCTest.so which is why it fails.

x86_64-pc-linux-gnu-readelf -Wd /Users/compnerd/Source/swift/build/Ninja-ReleaseAssert/xctest-linux-x86_64/libXCTest.so | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/Users/compnerd/Source/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/linux]

Adding it seems to make it work.

x86_64-pc-linux-gnu-readelf -Wd /Users/compnerd/Source/swift/build/Ninja-ReleaseAssert/xctest-linux-x86_64/libXCTest.so | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [/Users/compnerd/Source/swift/build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/linux:/Users/compnerd/Source/swift/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation]

Now, the thing is that Foundation.so is probably going to somewhere in the system root, so adding the DT_RUNPATH for the build environment doesn't really make much sense.

When installed, libFoundation.so will be adjacent to libXCTest.so in the distributed toolchain (`lib/linux`) so we could use rpaths...

Hmm, adding `$ORIGIN` to the rpath by default sounds safe and would fix it. A quick test (with adding `$ORIGIN` and symlinking libFoundation.so) does indeed work for me.

BTW, running a clean build after the changes with the LD_LIBRARY_PATH change reverted, the tests do seem to pass. Could this just be an oddity of the two linkers producing slightly different results confusing the loader?

Nope.

I believe the problem here, which I tracked down in SR-1631, is that gold defaults to embedding DT_RUNPATH into the library instead of DT_RPATH. I am not very familiar with dynamic library search mechanisms on Linux though, so I don't yet have a complete picture of how this breaks things.

Taking this. I fixed SR-1631, but I think the right fix here is to move to a toolchain based build process, at which point this workaround can maybe go away.

Finally removed this hack in #338