Additional Linux Distributions

just opened a PR with this info. still needs to be reviewed, but potentially helpful: add guide for adding ci dockerfiles to support more distributions by tomerd · Pull Request #171 · apple/swift-docker · GitHub

1 Like

In addition to the slim images mentioned above which we publish for ubuntu (CentOS and Amazon Linux 2 dont need anything on top of the distro for running swift programs), another option that folks could find interesting is Google's distroless. I did a small experiment today:

FROM swiftlang/swift:nightly-bionic as build

# build a test application, real world examples would add the actual source instead
RUN mkdir /workspace
WORKDIR /workspace
RUN swift package init --name test --type executable
RUN echo "import Foundation\n \
\n \
let dateFormatter = DateFormatter()\n \
dateFormatter.dateFormat = \"yyyy-MM-dd HH:mm:ss Z\"\n \
dateFormatter.timeZone = TimeZone(abbreviation: \"PST\")\n \
\n \
print(\"Hello, world!\")\n \
print(\"The time is \(dateFormatter.string(from: Date()))\")\n \
" > Sources/test/main.swift
RUN swift build -c release

# copy executables and dependencies on top of the base image
FROM gcr.io/distroless/cc-debian10
COPY --from=build /workspace/.build/release /
COPY --from=build /usr/lib/swift/linux/lib*so* /

# set the entry point (application name)
CMD ["/test"]

and the results:

❯ docker build . -t swift-distroless-test
Sending build context to Docker daemon   2.56kB
...
Successfully built 101536fea410
Successfully tagged swift-distroless-test:latest

❯ docker run swift-distroless-test
Hello, world!
The time is 2020-05-09 14:21:36 -0700

Note the above this uses gcr.io/distroless/cc-debian10 as the runtime image which should work for Swift programs that do not use FoundationNetworking or FoundationXML. In order to provide a more complete support we (the community) could put in a PR into distroless to introduce a base image for Swift that includes libcurl and libxml which are required for FoundationNetworking or `FoundationXML respectively.

3 Likes

Thank you for the information, can any of you please reply to my query.

Can we use the script to install swift on linux? like: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

sudo echo "deb [ trusted=yes ] https://swift.apt.compnerd.org/apt /" > /etc/apt/sources.list.d/swift.list
sudo apt update
sudo apt install swift-toolchain

worked for me but swift fails with:

<unknown>:0: error: unable to load standard library for target 'x86_64-unknown-linux-gnu'

Also I guess "swift package init" is not yet supported?

You might be interested in this: Introducing swiftbox 0.10 with CentOS(RHEL) and Amazon Linux support

regards,

Lars

Oh, the layout is similar to that on Windows, so you will need the -sdk flags.

I think that s-p-m builds are integrated into the packaging, help to add that is welcome :)

I tried

swift -sdk /Library/Developer/Platforms/Linux.platform/Developer/SDKs/Linux.sdk bla.swift

and then I get:

<unknown>:0: error: could not load the swift standard library

strace shows

openat(AT_FDCWD, "/Library/Developer/Toolchains/unknown-Asserts-development.xctoolchain/usr/lib/swift/linux/libswiftCore.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT

but doing

dpkg -L swift-linux-sdk|grep libswiftCore

gives

/Library/Developer/Platforms/Linux.platform/Developer/SDKs/Linux.sdk/usr/lib/swift/linux/libswiftCore.so

So it seems to search in the wrong place.

This is Ubuntu 20.04.

That sentence is confusing. Is it integrated or not? If it is what help is needed and if not, can you give a hint how to help?

That is really odd; I've definitely had this working on Ubuntu previously as I had this setup in docker with VSCode: https://github.com/compnerd/swift-build/blob/master/docs/GettingStartedDocker.md

I would recommend mirroring the Windows flags for now:

export SDKROOT=/Library/Developer/Platforms/Linux.platform/Developer/SDKs/Linux.sdk
swiftc -sdk ${SDKROOT} -I ${SDKROOT}/usr/lib/swift -L ${SDKROOT}/usr/lib/swift/linux -emit-executable -o /tmp/reduced /tmp/reduced.swift

Sorry, this is what happens with an early morning reply. The s-p-m builds are not integrated yet :-(. That is the help that is needed, the configuration for that is at https://github.com/compnerd/swift-build/blob/master/.ci/templates/linux-devtools.yml; updating that to finish building it and packaging it up into a dpkg (https://github.com/compnerd/swift-build/blob/master/.ci/templates/devtools-deb.yml) should enable it to be uploaded as well.

How is the versioning managed?

I'm not sure.

Pinging @Ron_Olson

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.

1 Like

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.

5 Likes

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?

OK, Thanks!

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:

Packaging status

1 Like

That fails with:

/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

Any ideas? (This is Ubuntu 20.04.)

The Ubuntu 18.04 (flowkey) build fails with

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.

1 Like

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.