Global ld.conf or switching symlinks to activate toolchain

[freef4ll]

In case application has been built by swift container, global library path needs to be deployed in order to find the Swift runtime in order to run the application not inside a container.

For example the RPATH will be set to /usr/lib/swift/linux, and if the toolchain is going to be deployed by Swiftly under /usr/local, it is not possible to execute binaries which are built by the container:

$ chrpath -l MySwiftBinary 
MySwiftBinary: RUNPATH=/usr/lib/swift/linux:$ORIGIN

One either needs to have a global entry like this (to avoid setting LD_LIBRARY_PATH for each application):

$ cat /etc/ld.so.conf.d/swift.conf 
/usr/local/share/toolchains/5.9.0/usr/lib/swift/linux

It would be nice that swiftly use would handle this use case.

[patrickfreed]

Swift on Linux doesn't have a stable ABI, so I'm not actually sure this is a use case that we want to encourage. For example, if the versions of the Swift runtime differed between the container and the deployed system, my understanding is that it may not / won't work. Instead, the binary should be compiled on the deployment hosts using the swiftly-installed toolchain, or the executable should be built in the container using --static-swift-stdlib.

[freef4ll]

Haven't had problems with minor versions, for example built with 5.8.1 and executed fine on a host that lagged(unintentionally) and had 5.8.0. I understand that there is no guarantees, but adding an additional 74MB on each binary adds large overhead for CI/CD pipeline.