We have a ticket open to implement static linking of swift libs.
If anyone on the Swift team knows how to do this and can comment here then I’m sure we can get it implemented pretty quickly.
Static vs dynamic building of libraries may also have an interesting impact on the build system, particularly in how we set visibility for emitted symbols. For executables and dylibs, our current mapping of access control to visibility and linkage makes sense:
- public has default visibility,
- internal has hidden visibility (__attribute__((visibility("hidden"))) in Clang),
- private has private linkage (like 'static' in C).
However, when statically linking a library into another executable or dylib, the static library's public symbols in most cases probably ought to become hidden in the final target, unless the dylib or executable explicitly reexports the static library's module somehow.
I’ve worried about such things, but my conclusions were there weren’t any practically compelling reasons to worry about it too much.
My reasoning being: when writing a Swift file the compiler won’t give you access to those symbols unless you `import` that module, in which case you want them.
Unless there is something I’m missing?