My understanding is that different linux distros do things slightly differently, eg naming the shared system libraries that the toolchain links against differently, so this is done to make sure the Swift toolchain works. Either the RHEL or CentOS builds should work for you on Fedora.
What I want to know is whether it is possible to distribute a single Swift SDK package that can be used on both ancient distributions like CentOS 7 and modern distributions like Ubuntu 22.04, Fedora 38, etc.
libedit: It is only used in lldb, is BSD licensed, and can be statically linked.
libpython: It is only used in lldb.
libncurses: It is used in various places. Most distributions have an older version of ncurses for compatibility reasons (libncurses5 for Debian, ncurses-compat-libs for Fedora).
Except for libpython, if we make slight modifications to the Centos 7 build, we can use the same Swift SDK on both Centos 7 and Ubuntu 22.04.
For Python, I believe that's why Xcode ships its own Python interpreter. We can do the same for Swift, as it is only used in lldb.
It’s about ABI. The libraries that things like corelibs foundation, dispatch, xctest, and even the main runtimes themselves use aren’t guaranteed to have the same layout across versions or across distributions. Copying libraries and executables built for one distro to another and running it might look like it works, but it’s certainly a happens-to-work situation and not a guaranteed to work situation. If you’re okay foregoing CXX/C interop with any existing libraries (read no shared objects that you didn’t build and no dlopen to thing you didn’t build) you could build an SDK that was isolated enough to maybe work this way. You would have to provide your own icu, libxml2, zlib, etc, and make very certain that you, nor your dependencies pulled in anything from the system or you’d end up with undefined behavior. It’s true that some of the libraries try to maintain ABI stability, but then we’d need to figure out what version started doing that and make sure that at least that version is used on your minimum deployment target.
Yes, Rust doesn't have as many dependencies as Swift does, especially in the core libraries (primarily Foundation). And it's not just Glibc, I don't think it has a strong dependency on lib(std)c++ as we do. Although Rust does have a Musl distribution too IIRC, which means you may not even need Glibc installed, or even a specific version of it.
Pretty much. Everything is completely statically linked with the exception of glibc and/or takes part in the cargo ecosystem. Take SQLite and the sqlite-sys package for example. Cargo will use the system headers and system library if available and build against that for local builds. Otherwise it will use the sources from its own package. That’s maybe okay for pure package content, but corelibs foundation/dispatch and friends don’t participate in that and can share memory objects across boundaries.
Yeah, from what I got from reading the sources, it looked like the main glibc dependency was on malloc. Otherwise everything else in std looked to be implemented in rust itself. I may have missed something, but I saw no C++.
Aha, I understand now. So there are much larger issues in runtime libraries required by Swift Foundations than the compiler itself. It is unfortunate that Swift cannot be distributed as a single binary like Go or Rust.
I think I need to find a way to distribute using flatpak or something like that to ensure that libicu and other dependencies are fixed.