* Daniel P. Berrangé: > Good to see it mentions autoconf, as such tests were my immediate > concern upon reading the intro. > > I presume the same problem will exist in other build systems that > probe for features, both well known ones like cmake/meson/etc, > but also home grown ones that are package specific (/me glares > at QEMU's 'configure' that merely pretends to look like it is > from autoconf, but is actually just a hand written shell script). Yes, some distributions use config.log diffing. I've got an instrumented GCC that logs the relevant errors in a way that is impossible to hide. There are pros and cons for each approach. I found one non-autoconf issue already: Unclear how CCompiler.has_function works for functions with parameters <https://github.com/pypa/setuptools/issues/3648> This is actually quite typical of the things that are papered over by implicit function declarations. >> == Dependencies == >> To avoid regressing the porting effort, GCC as the system compiler >> needs to reject obsolete constructs by default. This is expected for >> GCC 14, to be released as part of Fedora 40 in Spring 2024. > > So this change is talking about a new GCC landing in Fedora 40. > > To avoid massive disruption to Fedora though, we need to be doing > work waaaaay earlier than the Fedora 40 dev cycle though. Yes, I understand that we might be too late already. I wanted to get the announcement out of the door that we can start carrying patches for this in rawhide starting now (particularly where we might have cascading effects on our testing, like the has_function issue mentioned above). I don't think I can do this work on a branch because keeping that branch up-to-date will be too much work on its own. > Identifying all the places where autoconf tests quietly change > their result, and silently toggle on/off alternative code paths > is going to be a big job on its own. Right, but other distributions are doing this as well (Gentoo has already begun working on this from a Clang 16 perspective), and we are trying to come up with ways to share observations and patches. One tough aspect is that this affects disproportionately legacy software for which there is no upstream around anymore, or the sources are difficult to change because they are supposed to keep building on very, very old systems. We can switch to building in C89 mode in these cases. > I feel that this need to start on the prep work in F38/F39 is not > very obvious from the F40 change proposal text. I mentioned that package maintainers need to tolerate the odd patch to fix issues in rawhide. That's what I'm asking for today. > Concretely, as an upstream maintainer, what should they do to test > the behaviour of their code ? Is there more to it than just > setting CFLAGS="-std=gnu99", if they want to validate this in their > upstream CI ahead of GCC 14 arriving ? It's -Werror=implicit-int -Werror=implicit-function-declaration. Best to throw in -Werror=int-conversion -Werror=strict-prototypes -Werror=old-style-definition. -Werror=int-conversion should really be a no-brainer, the other two are about the removal of old-style function definitions and declarations that are not prototypes from C2X (also mentioned in the proposal). I can probably spell this out in the proposal. Some of the planned Clang 16+ and GCC 14+ changes may not be directly testable with current compilers, but they will be less impactful than the two main issues, I think. That's why I'm focusing to get us past the C99 bump first. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
