You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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:One either needs to have a global entry like this (to avoid setting LD_LIBRARY_PATH for each application):
It would be nice that
swiftly use
would handle this use case.The text was updated successfully, but these errors were encountered: