Downgrade to debian stretch

[notmgsk]

trafficstars

Debian Buster has glibc version 2.28. A number of people have complained that the SDK is broken for them, since their OS does not support that glibc version. Going back to Debian Stretch will mostly resolve that (glibc 2.27 is well supported). I don't think we lose much by downgrading debian.

On the other hand, there will always be someone whose glibc is not supported, and so maybe drawing the line at 2.28 and saying this is the version we officially support is the right way to go.

[notmgsk]

After some testing it looks like downgrading the debian version is not sufficient to keep glibc to <2.28. I suspect it's clang++-7 that is forcing glibc to upgrade.

[appleby]

fwiw, clang-7 doesn't appear to cause a glibc version upgrade on debian stretch. This is from a local debian:stretch container where I installed clang-7 (GLIBC 2.24 is the same version that ships with a default stretch install):

root@743f80e7d9dc:/# clang++-7 --version | grep version
clang version 7.0.1-8~deb9u2 (tags/RELEASE_701/final)
root@743f80e7d9dc:/# ldd --version | grep GLIBC
ldd (Debian GLIBC 2.24-11+deb9u4) 2.24
root@743f80e7d9dc:/# grep VERSION= /etc/os-release
VERSION="9 (stretch)"

[appleby]

also here is a little table I put together while testing some sdk-packaging changes of a handful of common distros and their default libc / libstdc++ versions, plus the result of attempting to install the .deb / .rpm on that distro when the binaries were built using debian:buster

Building on Debian Buster against libstdc++-6-dev

distro	glibc	libstdc++	install ok?
debian 9 (stetch)	2.24	6.3.0	☠️ libc deps
debian 10 (buster)	2.28	8.3.0	✅
ubuntu 16.04.6 LTS (xenial)	2.23	5.4.0	☠️ libc deps
ubuntu 18.04.3 LTS (bionic)	2.27	8.3.0	☠️ libc deps
centos 7	2.17	4.8.5	☠️ libc deps
centos 8	2.28	8.2.1	✅ (but must enable PowerTools repo)
fedora 29	2.28	8.3.1	✅
fedora 30	2.29	9.2.1	✅

edit: at the time of writing, the above table represents the current and previous versions for these distros (with ubuntu limited to LTS releases)

[stylewarning]

I strongly support downgrading ASAP. This is causing lots of user issues.

[appleby]

After some testing it looks like downgrading the debian version is not sufficient to keep glibc to <2.28. I suspect it's clang++-7 that is forcing glibc to upgrade.

Did some more poking at this. The problem dependency is actually libstdc++ (or libc++), not clang-7, which only requires libc >= 2.19 on debian stretch, but also uses an old libstdc++ 6.3.0. Tweedledum requires C++17 support, which means at least libstdc++ >= 7 or libc++ >= 4, though the min required version will depend on exactly which C++17 features tweedledum uses. Probably safest to target the min supported versions claimed in the tweedledum README, i.e. the ones that ship with GCC 7.3.0 / Clang 6.01.

Unfortunately, AFAICT, upgrading libstdc++ on debian stretch means enabling the testing repo, which will also pull in a very recent libc, as @notmgsk mentions.

Here are some (untested) things we might try:

• Try building tweedledum against the libc++1-7 that comes with debian stretch. This requires adding a libc++ runtime dependency.

• Build our own compiler toolchain, ship our own libstdc++ or libc++ alongside libtweedledum. For example, the libstdc++6 (8.3.0) package for debian buster claims it only depends on libc6 >= 2.22.

[appleby]

Here are the results of testing out the first suggestion from my previous comment, namely building on debian stretch against libc++-7-dev rather than libstdc++. The distros/versions tested are the same as the above table for building on debian buster against libstdc++.

Compared to the current situation as outlined in the above table, we'd gain support for debian 9 and ubuntu 18.04, but lose support for centos 8, since I couldn't find libc++ in any of the centos 8 repos, not even EPEL! I suspect ubuntu and debian are more popular desktop environments than CentOS though, so this is probably a net win.

Building on Debian Stretch against libc++-7-dev

distro	glibc	libc++	./quilc -S
debian 9 (stretch)	2.24	3.5, 7.0	✅
debian 10 (buster)	2.28	7.0	✅
ubuntu 16.04.6 LTS (xenial)	2.23	3.7	☠️
ubuntu 18.04.3 LTS (bionic)	2.27	6.0, 7.0	✅
centos 7	2.17	3.8	☠️
centos 8	2.28	n/a!	☠️
fedora 29	2.28	7.0	✅
fedora 30	2.29	8.0	✅

For distros that have more than one version of libc++ available in their repos, I list the min version and the first version recent enough to satisfy tweedledum's C++ 17 requirements (i.e. libc++1-7 / libc++-7-dev on debian-derived distros).

The bottom line is that while libc++ dependencies are a little easier to satisfy than libstdc++, you're still at the mercy of whatever versions the distro provides in their package repositories.

[notmgsk]

I think CentOS is the OS used on the QMI and so being unsupported there would be less than ideal.

[stylewarning]

@notmgsk @appleby What's the resolution here?

[appleby]

The docker image was downgraded to debian stretch in #4 and tweedledum was disbaled in quilc in https://github.com/rigetti/quilc/pull/475.

With those two changes, all the sdk is working again on all distros / versions in the above table, plus a couple more we tested. notmgsk created a google doc with the details. I'll send you the link.