[swift-users] building static binaries / reducing library dependencies?

[Brian Swetland]

I've noticed that the standard "swift build" binaries are dynamic (which
makes sense), and there are quite a few dependencies.  For a trivial hello
world, the hello binary depends on:
libswiftCore.so
libstdc++.so.6
libm.so
libgcc_s.so.1
libc.so.6

and libswiftCore.so further depends on:
libpthread.so.0
libdl.so.2
libicuuc.so.55
libicui18n.so.55
libbsd.so.0
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
ld-linux-x86-64.so.2

If I want to build something I can hope will run on other linux machines
with potentially arbitrary distributions, it'd be really nice to be able to
build fully static, or at least more self-contained binaries.

Both license-wise and operationally, linking glibc staticly is problematic,
but at least glibc has very strong backward compatibility with itself.
libstdc++ on the other hand is something I'd always want staticly linked to
not be at the whim of ABI breakages from release to release.

I'm curious about the libstdc++ dependency, since I was under the
impression the swift runtime was written in swift.  What part of the
runtime or generated code causes this dependency to exist?

The libc dependency could be simplified by supporting musl-libc (small, MIT
licensed, pretty source-compatible with glibc).

Given that libbsd and libicu are under permissive licenses and libstdc++
(if it's needed) has a linkage exception), it'd be nice to have a way to
include those staticly (in either libswiftCore.so or final binaries),
resulting in the only remaining dependencies being on
libc/libc/libpthread/libdl which have extremely robust and well maintained
API/ABI backward compatibility.

This should allow for linux binaries which have significantly better
chances of working correctly on an arbitrary linux machine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20151203/8751046b/attachment.html>