[swift-users] statically link the standard library on Linux

Joe Groff jgroff at apple.com
Fri Feb 19 14:55:49 CST 2016

> On Feb 19, 2016, at 12:37 PM, Max Howell <max.howell at apple.com> wrote:
>>> 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?

Maybe not huge problems, but it's a secrecy violation and unwanted ABI liability, and also limits LTO-level optimization opportunities since exported functions have to preserve their existence and calling convention.


More information about the swift-users mailing list