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

[Joe Groff]

> On Feb 19, 2016, at 1:06 PM, Max Howell <max.howell at apple.com> wrote:
> 
>>>> 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.
> 
> Makes sense, can we solve it? Our current direction is certainly one of: stuff all the (library) modules into a single linkage unit, be that a single dylib, a static library or a framework.

If the frontend knows it's building for a static library, it could conceivably set the correct visibility contingent on that flag. There may also be ld flags to suppress exporting symbols from particular .o and .a files post-hoc.

-Joe