I only release "-RELEASE" versions; typically I try to build it the same day as I get the notification from GitHub that the Release version is available. There's typically a week (two in the case of RHEL/CentOS) of testing from getting the rpm built to it being pushed to stable and subsequently available as part of a dnf update or new installation.
I'm highlighting this because Swift has no ABI guarantees on Linux β installing a new Swift version immediately invalidates all binaries built previously that still reside on the system. It's something that I generally warn against.
Ouch. Are there any actual plans to fix this? Meanwhile it's probably OK to set the soname to the full version.
Did it actually break between subminor versions, or is it a precaution that it might?
Are those packages doing a distinction between a Swift runtime package and a -dev one? Or are they one big blob?
I just found this repology page, that lists all package repositories with a Swift compiler. I added the Termux package for Android listed there last month: you can write basic Swift code (only stdlib so far, working on cross-compiling the corelibs and Swift package manager to Android) on most Android phones and tablets (64-bit AArch64 running Android 7 or later) by installing the Termux app and typing pkg install swift.
If there's interest, I can submit a pull to add the repology badge listing all Swift repositories, from this page of badges, to the Swift README:
/usr/bin/ld.gold: error: cannot open Scrt1.o: No such file or directory
/usr/bin/ld.gold: error: cannot open crti.o: No such file or directory
/usr/bin/ld.gold: error: cannot open crtbeginS.o: No such file or directory
/usr/bin/ld.gold: error: cannot open crtendS.o: No such file or directory
/usr/bin/ld.gold: error: cannot open crtn.o: No such file or directory
/usr/bin/ld.gold: error: cannot find -lgcc
/usr/bin/ld.gold: error: cannot find -lgcc_s
/usr/bin/ld.gold: error: cannot find -lc
/usr/bin/ld.gold: error: cannot find -lgcc
/usr/bin/ld.gold: error: cannot find -lgcc_s
2020-05-14T13:18:13.3647816Z CMake Error at CMakeLists.txt:45 (find_package):
2020-05-14T13:18:13.3648536Z Could not find a package configuration file provided by "Yams" with any of
2020-05-14T13:18:13.3649087Z the following names:
2020-05-14T13:18:13.3649666Z
2020-05-14T13:18:13.3650275Z YamsConfig.cmake
2020-05-14T13:18:13.3650939Z yams-config.cmake
After a quick look I wasn't able to find said CMakeLists.txt. Can you give me a pointer?
That's true. Up until 5.2.x swift-lang-runtime was a subpackage of swift-lang but ultimately with no ABI guarantee it seemed like the runtime package was making a promise that couldn't be delivered; so with 5.2.x I removed it.
I recall there was breakage back in the 4.x versions, I've had success running 5.2.1 binaries against later versions of 5.2. I mentioned below that I did break out runtime into a separate sub-package, but since there was no guarantee it would work with later versions, I figured having the whole thing available for easier recompilation would be better.
The problem is that people are just going to end up to depend on the whole swift toolchain to get the runtime?
I think it would be preferable to just have the different runtime versions available. E.g. libswift5.2.1.rpm having libswift5.2.1.so with the soname set to the full 5.2.1. So that parallel installs of binaries work.
I mean it is not like we get a new Swift version every two weeks
I did consider, early on, having a totally separate Swift Runtime package that was separate and exclusive from the Swift package, that was versioned and added to /usr/ld.so.conf.d in way similar to how LLVM does it, but it got dropped just trying to get Swift working. It might be worth considering doing that now.
The link failures are due to missing dependencies. You should install: libc6-dev libgcc-8-dev libncurses-dev libstdc++-8-dev and that should then succeed to link.
Note that this is what the docker image that I create is for - it basically packages the toolchain and the small set of packages needed to use it. Additionally it includes a copy of VSCode that runs entirely in the docker image. Ideally, it would be setup with SourceKit-LSP and everything but I've got a bunch of other stuff to do. If you want to help push forward on that, Im happy to have help!
Oh, I didn't notice the failures because Im dealing with a pretty nasty runtime issue at the moment.
Seems that s-p-m has grown a dependency on Yams which I've not added to the build yet. This is more tricky as the repository needs to be cloned on all jobs as otherwise we end up with longer builds. Seems reasonable to add that though.
It might be instructive to look at how the distributions deal with packaging LLVM, which has the same general issue of no ABI guarantees for most of its libraries.
sudo apt install libc6-dev libgcc-8-dev libncurses-dev libstdc++-8-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6-dev is already the newest version (2.31-0ubuntu9).
libncurses-dev is already the newest version (6.2-0ubuntu2).
libgcc-8-dev is already the newest version (8.4.0-3ubuntu2).
libstdc++-8-dev is already the newest version (8.4.0-3ubuntu2).
I'd like the deb packages to be in a state where they could be uploaded to Debian. Since Ubuntu basically imports everything from there Swift would be very easy to install on a huge number of computers (Debian, Ubuntu, all other derivatives), just like clang: Debian -- Details of package clang in sid
If you can guide me I'm willing to invest some time.
