On Fri, Feb 05, 2021 at 05:52:59PM +0100, Thomas Huth wrote: > On 05/02/2021 17.23, Peter Maydell wrote: > > On Fri, 5 Feb 2021 at 16:21, Stefan Hajnoczi <stefa...@redhat.com> wrote: > > > Thanks, I update the patch in question. > > > > > > It looks like the GitLab CI doesn't include a clang version that > > > produces this error because the pipeline passed for me: > > > https://gitlab.com/stefanha/qemu/-/pipelines/251524779 > > > > > > Is there something clang-specific you want to check in the CI? Maybe > > > clang 3.4, the oldest version supported according to ./configure? > > > > Would probably be nice I guess. My ad-hoc builds use clang 6, > > which is what tripped up here. > > We should maybe discuss first whether we can bump the minimum version of > Clang that we would like to support. I once picked Clang 3.4 since that was > available in EPEL for RHEL7, but I think there were newer versions of Clang > available in RHEL7 via other repos later, so 3.4 is likely really just way > too old now... > > According to https://developers.redhat.com/HW/ClangLLVM-RHEL-7 there was at > least Clang 7.0 available on RHEL7. Debian stable seems to have at least > 7.0, too, according to repology.org. Ubuntu 18.04 seems to have version 6, > but later ones are available via updates? Anyway, I think we could at least > bump the minimum version to 6.0 nowadays...
Per our support matrix, this is the last dev cycle where we need to care about RHEL-7, as RHEL-7 will be past the 2 year cutoff in the QEMU 6.1 cycle. Furthermore given that CLang was only ever an EPEL package, not a core part of the distro, I think we are justified in just ignoring RHEL-7 already for purpose of choosing CLang min version. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|