I am currently trying to migrate my toolchain from 21.1 to the most current 22.2. However, I am aware that there may exists support issue on my updated OS.
On my reading the version 22.2 HPC SDK Platform Requirements, I am noticing that there has been hardly any update on the supported Linux distros since 21.1. The latest supported platforms have been still on things like RHEL 8.2 / Ubuntu 20.04 / CentOS 8.2 (EOL) / Fedora 32 (EOL) / OpenSUSE LEAP 15.1 (EOL).
Is there any plan of compatibility test and updates on newer (and maybe more) Linux distros?
I should note that by “supported”, this just means that we’ve tested the compilers on these particular systems. Though, especially for minor distribution releases, there’s good compatibility between OS releases, so the compilers are likely to work fine on new distributions. Unfortunately due to sheer number of distributions and versions, it’s difficult to maintain testing on all of them.
We do periodically update our OS distribution matrix, largely based on user feedback. So if you do encounter an issue, or have particular distribution you’re looking for, let us know, and we can see about adding it.
I asked engineering and they are currently considering adding Rocky Linux or possibly another as a potential CentOS successor.
Thanks for your reply. I do understand that it is basically meaningless and impossible to get things tested on all distros and versions. However, on the end users’ side, as people not only use the compilers on supercomputers but also on workstations which receive periodic version updates, I would think that it can be pretty beneficial to have some updates, at least towards the most current living versions for the distros listed in the documentation (e.g. Fedora is currently at 34/35, and RHEL is now at 8.5).
Thanks.
Loc
Edit:
I do wonder what the deterministic factor is for those OS compatibility. From my personal knowledge, I could only think of the CUDA & GCC version match and the kernel driver support, but maybe there are more of them?
Yes, there’s not really a lot of things anymore but a few. We ship CUDA with the HPC SDK, so that shouldn’t a problem for the compilers, provided CUDA itself doesn’t have issues. The CUDA drivers are a separate issue and not directly related to the compiler’s OS compatibility.
For interoperability with g++, we do need to use the GNU STL which can sometimes cause problems. But this isn’t directly tied to the OS so we test against GNU versions independent of the OS.
We used to have ship our own variants of a few system headers to workaround “GNUism” which caused problems when the system header files changed, but since we added g++ interoperability and define “GNUC”, this is less of a problem.
I’ve occasionally seen issues with updated binutils, i.e the linker “ld”, and assembler, “as”, but that’s very rare.
Long ago (~15-20 years ago), the OSs would sometimes break libc computability, which was painful, but luckily this doesn’t happen any more.
Not to say that there can’t be issues when trying to install the compilers on a newer OSs than what we officially support , but it’s become much more rare, especially with minor OS releases.
Thanks for your answer! I am currently on Debian 11 and I will dig a bit more to see if it works.
Actually, in my personal opinion, it will be totally unnecessary for the engineering to keep things on the EOL’d distros. Likely nobody in the world should be still running Fedora 29 or 30, but timely update on Fedora 35 (36 in the near future) would be helpful.
Another choice may be to provide a containerized image, from which we can just get out of the supported distro problem and just have things compiled insider docker.