We need to upgrade our GCC in cenbuild. It's well overdue, and it's needed for the QT project (bug 8337).
This also includes upgrading binutils. And prerequisites for this are: * Raise the glibc requirements * Upgrade various base packages in cenbuild
We have upgraded gcc before. The two last times were tracked under bug 7362 and bug 5430. It can be helpful to see examples of issues encountered during gcc upgrades in the past.
This upgrade is likely to cause a lot of fallout. GCC has apparently decided to clean up a 20 year old technical debt. C99 removed support for a few dangerous constructs. gcc (and everyone else) decided at the time to just make warnings out of those. But now they've decided to promote them to errors¹. ¹The error messages in gcc still state "[-W...]" though for maximum confusion There has been a concentrated effort from e.g. Fedora to fix all the projects that still rely on pre-C99 behaviour and I assume it has gone well since they've gone ahead and released this change to the general public. But it means that we'll likely see issues when using any software not released recently. To make things worse, it is apparently popular to use these old constructs in configure checks. So a lot of configure scripts will mis-detect things, and it might not be obvious they've done so unless you examine everything closely. clang has also made the same change, so this is the heading everyone is going. Although painful, I don't see any point in resisting this change. We'll just have to deal with the transition. Some more details available on this GCC bug here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092 For reference, the warnings promoted to errors are: -Wimplicit-int -Wimplicit-function-declaration -Wint-conversion -Wincompatible-pointer-types
One issue that popped up is the mess around 64-bit ints and printf() on Windows. The standard specifier for that is "%lld", but Microsoft went another way and uses "%I64d". For this reason, MinGW optionally provides their own printf() family of functions that more closely follows the standard. But things change over time, and our mix of old and new can confuse things. New versions of Windows support both %lld and %I64d. Unknown when this support was added, as Microsoft hasn't documented anything. I tested on Windows 10 and 11. It also doesn't require UCRT as I tested with the classical MSVCRT. However, our current gcc (5.5.0) assumes Windows doesn't support %lld, so it will complain: > printf.c:7:12: warning: unknown conversion type character 'l' in format [-Wformat=] > printf("%llx\n", x); You can silence this by telling it to use MinGW's printf() using "-D__USE_MINGW_ANSI_STDIO=1". The new gcc (14.2.0) is silent by default, as it seems to assume Windows will support %ll. However! Both old and new gcc will complain about %I64d instead if you specify "-D__USE_MINGW_ANSI_STDIO=1": > printf.c:8:17: warning: 'I' flag used with '%x' gnu_printf format [-Wformat=] > 8 | printf("%I64x\n", x); This is an incorrect warning, as MinGW's printf() supports %I64d just fine. There is a bug report about this upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110998 To add to this, modern MinGW seems to default to their own printf(). If I compile my test program with Fedora's MinGW, I get complaints about %I64d even without "-D__USE_MINGW_ANSI_STDIO=1".
