[Pitch] Package Manager: Statically link Swift runtime libraries by default on supported platforms

[t089 (Tobias)]

@tomerd

• Package the application with a "bag of shared objects" (the libswift*.so files making up Swift's runtime libraries) alongside the program.
• Statically link the runtime libraries using the --static-swift-stdlib flag described above.
• Use a "runtime" docker image that contain the correct version of the the runtime libraries (matching the compiler version exactly).

I have a question here for Docker/container experts. Wouldn’t option 3 offer the advantage that the container runtime can cache the „Swift runtime library“ layer, such that when you deploy multiple apps on a node that all use the same container base image with the same Swift runtime libraries you should actually safe space and benefit from caching on the host/node? Whereas when every app statically links the runtime, you will potentially waste image space. So, I’m challenging a bit if we can really say that static linking is preferable for containerized deployments. I would have assumed containers are an excellent way to provide the runtime libs efficiently as a shared container layer.

[tomerd]

@t089

I have a question here for Docker/container experts. Wouldn’t option 3 offer the advantage that the container runtime can cache the „Swift runtime library“ layer, such that when you deploy multiple apps on a node that all use the same container base image with the same Swift runtime libraries you should actually safe space and benefit from caching on the host/node? Whereas when every app statically links the runtime, you will potentially waste image space. So, I’m challenging a bit if we can really say that static linking is preferable for containerized deployments. I would have assumed containers are an excellent way to provide the runtime libs efficiently as a shared container layer.

yes, using docker containers can help users optimize for binary size. as mentioned in the proposal, the trade-off here is binary size vs. safety and convenience: when using a docker container as the provider of the runtime libraries you must match the exact compiler version you built with (eg if you built with 5.2.1 you must also use a docker container with the 5.2.1 runtime) and getting it wrong can lead to runtime issues which are usually unfortunate. the proposal makes the claim that we should pick the safer default (static inclusion of the runtime libraries), and those users that want to optimize for binary size could opt-out, vs. the other way around which is the default today.

[Cyberbeni (Benedek Kozma)]

I have a GitHub action that builds command line tools and caches them, so if you want to run swiftformat lint for all PRs, it can be easily run on Linux (as it will load from cache most of the time) instead of taking up the macOS slots: GitHub - Cyberbeni/install-swift-tool: GitHub Action to build and cache any Swift based tool in workflows.

Currently the cache UUID depends on both uname -v and swift -version when not running on macOS.

If I was using --static-swift-stdlib, would that mean that I could run a program on Ubuntu 20.04 that was built on Ubuntu 18.04? Or would I still have to use lsb_release -c (and arch of course) to calculate a UUID? Or do the dependencies have an even stricter requirement?

[lukasa (Cory Benfield)]

@Cyberbeni

If I was using --static-swift-stdlib , would that mean that I could run a program on Ubuntu 20.04 that was built on Ubuntu 18.04 ?

Sometimes. It depends what that package links. If that package only links C libraries with stable ABIs on Linux then yes. Otherwise, no.