Ubuntu 14.04

Currently, snapshots of master are produced for Ubuntu 14.04, 16.04 and 18.04 - the three current LTS versions of Ubuntu. End-of-life for Ubuntu 14.04 is scheduled for April 2019.

Although to my knowledge there has not been a public announcement of Swift 5's planned release date, historically Swift has released in March (Swift 2.2 was March 2016 and Swift 3.1 was March 2017).

If Swift 5 is released around March 2019 that would be only a month before the end-of-life of Ubuntu 14.04. I don't believe it would be worth releasing an Ubuntu 14.04 package in that case.

Proposal: we should stop building master on Ubuntu 14.04 now, do not release any swift-5.0 convergence snapshots for Ubuntu 14.04, and do not release Swift 5 for Ubuntu 14.04.

Tagging a few folks who might have views: @millenomi, @Tony_Parker, @spevans, @tanner0101, @weissi, @tkremenek


I wonder if it is possible to get some download stats for the .tar.gz to see if anyone actually downloads it?

I guess if we support if for Swift5 that would mean supporting it until the last 5.x release which could be the end of 2019. Although from my perspective the biggest problem with 14.04 has always been that it is in the wrong place in the CI chain. Code and tests only fail after merging to master because 14.04 tests only run post-merge. If this was fixed it would catch issues at the PR test stage.

If it is being used in sufficient numbers I have no problem supporting it, but if it was removed I wouldn't miss it.

1 Like

Thanks, Simon. I'm not sure what it would mean for us to support Swift 5 running on an unsupported operating system.

Download stats would be interesting, as you say.

By the way, do you know what is stopping us being distribution agnostic? Go and Rust just offer x86_86 tarballs that install into /usr/local regardless of distribution. It would be nice if Swift could do the same, then all this becomes history.

1 Like

+1 from me.

I think we should start thinking what is needed to compile Swift on Linux so the resulting toolchain and binaries are distribution- and version-agnostic as other languages do. If we embed libicu and any other distribution or version dependent library on the toolchain this should be relatively easy.

1 Like

travis-ci, who cannot be accused of being too cutting-edge, have just recently made 14.04 their default deployment environment. 16.04 was made available weeks ago. In other words, it seems early to drop 14.04 support from the perspective of any Travis user. A version-agnostic release, if possible, would be the best situation.

1 Like

Is this only tied to dependencies from the OS? I read about libicu being a specific requirement that begs for trouble and that we might build it along the swift toolchain now. I agree that a version-agnostic release would be the most desirable solution.

For what it's worth, I've successfully/painlessly transitioned my scripts from travis's 14.04 environment to their 16.04 environment. Other people who use travis for Swift testing would probably have success as well. Maybe dropping 14.04 won't be a problem from this point of view.

1 Like

Some more data

  • LLVM will soon require GCC >= 5.1 to build; Ubuntu 14.04 has 4.8.
    • We already use clang to compile swift, but we are using libstc++4.8
    • llibstdc++4.8 has known bugs with -std=c++14
    • It may be possible to update gcc, or for us to move to using libc++, but we will need to do something soon.
  • Ubuntu 14.04 is not useable from PR testing, so it's easy to accidentally break it and there is no way to PR test it even if you want to.

I am strongly in favour of dropping Ubuntu 14.04 for master and swift-5.0. We also have the ongoing swift-4.2.x releases (CC @johannesweiss), which should probably be considered explicitly.


CC @server-workgroup

+1 on moving away from 14.04. The old compiler has caused problems with libdispatch's build as well for SourceKit.

I believe CMake is also quite old on 14.04 and given that most of the repos are using it now, being held back by an old version could cause problems in the future.

Im happy to drop it for 5.0, especially if we can produce 4.2.x releases until its EOL in April.

As to running versions compiled for later versions on 14.04, it seems to be glibc++ causing problems:

$ ./swift-DEVELOPMENT-SNAPSHOT-2019-02-03-a-ubuntu16.04/usr/bin/swift
./swift-DEVELOPMENT-SNAPSHOT-2019-02-03-a-ubuntu16.04/usr/bin/swift: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./swift-DEVELOPMENT-SNAPSHOT-2019-02-03-a-ubuntu16.04/usr/bin/swift)
./swift-DEVELOPMENT-SNAPSHOT-2019-02-03-a-ubuntu16.04/usr/bin/swift: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./swift-DEVELOPMENT-SNAPSHOT-2019-02-03-a-ubuntu16.04/usr/bin/swift)
./swift-DEVELOPMENT-SNAPSHOT-2019-02-03-a-ubuntu16.04/usr/bin/swift: /lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by ./swift-DEVELOPMENT-SNAPSHOT-2019-02-03-a-ubuntu16.04/usr/bin/swift)

Yikes, we're currently asking developers on 14.04 to build a newer cmake from source to workaround this :expressionless: https://github.com/apple/swift/blob/master/docs/Ubuntu14.md#upgrade-cmake

Wait, LLVM can’t build itself?

You can use clang to build itself (and we do), but on Linux the C++ standard library we use by default is libstdc++, which matches the gcc version.

1 Like

+1, as you say 14.04 will be EOL in April which is only months away now.