-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Downgrade to debian stretch #3
Comments
After some testing it looks like downgrading the debian version is not sufficient to keep glibc to <2.28. I suspect it's |
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):
|
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
edit: at the time of writing, the above table represents the current and previous versions for these distros (with ubuntu limited to LTS releases) |
I strongly support downgrading ASAP. This is causing lots of user issues. |
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:
|
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
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. |
I think CentOS is the OS used on the QMI and so being unsupported there would be less than ideal. |
The docker image was downgraded to debian stretch in #4 and tweedledum was disbaled in quilc in quil-lang/quilc#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. |
As of Dec, 2021, we run re_dms on Ubuntu 18.04 which has glibc 2.27. However, Rust official docker images are based on directly on Debian. Ubuntu 18.04 is based on Debian Buster, however Buster runs glibc 2.28. Hence, building our executable against a Buster Debian image breaks because it expects glibc 2.28 at runtime (and it's not there). We've essentially created our own Rust docker image against Ubuntu 18.04 in order to build our executable guaranteed to be compatible with our deploy target. A breakdown of Debian/Ubuntu glibc deps can be found here: rigetti/docker-lisp#3 (comment)
As of Dec, 2021, we run re_dms on Ubuntu 18.04 which has glibc 2.27. However, Rust official docker images are based on directly on Debian. Ubuntu 18.04 is based on Debian Buster, however Buster runs glibc 2.28. Hence, building our executable against a Buster Debian image breaks because it expects glibc 2.28 at runtime (and it's not there). We've essentially created our own Rust docker image against Ubuntu 18.04 in order to build our executable guaranteed to be compatible with our deploy target. A breakdown of Debian/Ubuntu glibc deps can be found here: rigetti/docker-lisp#3 (comment)
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.
The text was updated successfully, but these errors were encountered: