[swift-users] statically link the standard library on Linux
tanadeau at gmail.com
Tue Feb 23 20:17:05 CST 2016
The --exclude-libs linker option does exactly that.
On Fri, Feb 19, 2016 at 4:08 PM, Joe Groff via swift-users <
swift-users at swift.org> wrote:
> > 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.
> swift-users mailing list
> swift-users at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-users