Continuing the discussion from [PITCH] Support for binary dependencies:
As discussed in that thread, shipping binary dependencies on Linux is not very easy. However, given the desire of SwiftPM to keep a simple build system it is probably still something we want to do, as there will be many C/C++ libraries that are not capable of being forced into the shape that SwiftPM wants them to be in to compile.
The best route for an interested party to go down is probably to borrow the hard work of the Python community in terms of manylinux. This was an attempt to define a restrictive subset of the Linux platform that can be safely used as a baseline for shipping compiled dependencies.
The current state of the art for manylinux is the manylinux2010 variant, defined here. Even this very conservative target is probably not sufficient for us, as it uses CentOS 6 as its baseline Linux, which I am not certain Swift currently supports.
For a detailed analysis of manylinux I will refer you all to the PEPs linked above, but here's a rough summary. manylinux notes that the only way to produce binary packages that are truly portable across multiple Linuxes is to restrict the number of binaries you link to to a tiny set that have a stable ABI across a wide range of Linux versions. To get this range to be acceptably wide you end up having a very restrictive environment. As of manylinux2010 you may link the following libraries at these specific SONAMEs:
libgcc_s.so.1 libstdc++.so.6 libm.so.6 libdl.so.2 librt.so.1 libc.so.6 libnsl.so.1 libutil.so.1 libpthread.so.0 libresolv.so.2 libX11.so.6 libXext.so.6 libXrender.so.1 libICE.so.6 libSM.so.6 libGL.so.1 libgobject-2.0.so.0 libgthread-2.0.so.0 libglib-2.0.so.0
As some additional limitations, you may only ship binaries compiled for the two architectures supported by CentOS 6: x86_64 and i686, and for libraries with versioned symbols there is a restricted maximum version you may use.
Naturally, this may appear to the Swift community to be a really quite extremely restrictive environment. It intentionally is. In principle we as a community could define a slightly less restrictive one, but in practice it would be very hard to do so in a meaningful way.
An added source of difficulty here is that Swift is pretty happy to link a wide range of libraries itself. Those libraries become something that a manylinux-type distributed binary cannot include within itself, as there is a risk of symbol clash leading to subtle breakage. We would, as a community, need to address how we handle the ABIs for those dependencies as well, or whether it is even possible for binary packages on Linux to use them.
Regardless, if we want to support binary packages in Linux without being extremely fine-grained about how we advertise their supported platforms, this appears to be the only possible strategy.