This message is a brief update where we are in terms of the Modern C port.
https://fedoraproject.org/wiki/Changes/PortingToModernC
We recorded fixes for about 850 packages for compatibility with a future compiler that does not support implicit ints nor implicit function declarations. Patches have been contributed upstream were feasible, and have already been merged by upstream maintainers in many cases. Changes have been backported into rawhide as well. Not surprisingly, there is an overlap between packages which need fixes and packages which are unmaintained upstream. On the other hand, some of the required fixes came in with regular upstream rebases.
https://gitlab.com/fweimer-rh/fedora-modernc
There are about 35 packages which had to be switched to building in C89 mode. Porting them required too many changes, or based on the existing compiler errors, they looked broken on 64-bit architectures anyway (so these packages are probably not used anymore).
https://bugzilla.redhat.com/show_bug.cgi?id=2137516
About 15 packages are currently waiting for maintainer help, such as rebasing to a new upstream version with fewer issues, or just waiting for retirement. The latter is about a few packages which still build by accident, but are completely unusable at run time because required functions (e.g., from the Python C library) are missing.
https://bugzilla.redhat.com/show_bug.cgi?id=2137512
I am going to explore a way to land -Werror=implicit-int -Werror=implicit-function-declaration among the default compiler flags. (We have already seen compatibility regressions due to upstream rebases.) There's a bit of an issue because the C++ front end warns on those flags, so we need another -specs= kludge that is incompatible with Clang. Once we have support for that in redhat-rpm-config, I'm going to switch the 35 packages mentioned above to using that new exemption mechanism (where feasible). This will also allow us to close out a few of the remaining help-needed issues, for those packages that require C89-only language features and C99-style inlining, which GCC does not support in C89 mode.
We are also exploring what to do about automatic conversion between integer and pointer types. This is a persistent source of 64-bit incompatibilities, so worth addressing. The work on implcit ints has addressed most incompatibilities in this area, but there are about 170 packages that need to investigated specifically for int-conversion issues. I suspect many of them are false positives because GCC issues type errors even if the function parameter list length does not match (so an int-conversion error in one argument does not matter because the configure check always fails on GNU/Linux anyway). It may be possible that it is not possible with these int-conversion issues in the Fedora 40/GCC 14 time frame due to capacity issues on our side.
Thanks, Florian
Florian Weimer wrote:
I am going to explore a way to land -Werror=implicit-int -Werror=implicit-function-declaration among the default compiler flags. There's a bit of an issue because the C++ front end warns on those flags, so we need another -specs= kludge that is incompatible with Clang.
It sounds like those parameters should be added only to CFLAGS, not to CXXFLAGS.
__global_compiler_flags already contains things that cause warnings from the Ada and Fortran compilers. The Ada packages get the warning “'-Werror=' argument '-Werror=format-security' is not valid for Ada” over and over. It doesn't break any builds but it's annoying noise in the build logs.
It would be better if __global_compiler_flags would contain only language-independent parameters, and language-specific parameters were added in build_cflags and build_cxxflags.
Björn Persson
On Wed, May 10, 2023 at 12:09:10AM +0200, Björn Persson wrote:
Florian Weimer wrote:
I am going to explore a way to land -Werror=implicit-int -Werror=implicit-function-declaration among the default compiler flags. There's a bit of an issue because the C++ front end warns on those flags, so we need another -specs= kludge that is incompatible with Clang.
It sounds like those parameters should be added only to CFLAGS, not to CXXFLAGS.
__global_compiler_flags already contains things that cause warnings from the Ada and Fortran compilers. The Ada packages get the warning “'-Werror=' argument '-Werror=format-security' is not valid for Ada” over and over. It doesn't break any builds but it's annoying noise in the build logs.
GCC 13 has a solution for that, one can add -Wno-complain-wrong-lang to -Werror=format-security etc. and avoid such warnings (that some compiler option is only appropriate for a subset of GCC languages and it is compiling some other language).
Jakub
Jakub Jelinek wrote:
On Wed, May 10, 2023 at 12:09:10AM +0200, Björn Persson wrote:
Florian Weimer wrote:
I am going to explore a way to land -Werror=implicit-int -Werror=implicit-function-declaration among the default compiler flags. There's a bit of an issue because the C++ front end warns on those flags, so we need another -specs= kludge that is incompatible with Clang.
It sounds like those parameters should be added only to CFLAGS, not to CXXFLAGS.
__global_compiler_flags already contains things that cause warnings from the Ada and Fortran compilers. The Ada packages get the warning “'-Werror=' argument '-Werror=format-security' is not valid for Ada” over and over. It doesn't break any builds but it's annoying noise in the build logs.
GCC 13 has a solution for that, one can add -Wno-complain-wrong-lang to -Werror=format-security etc. and avoid such warnings (that some compiler option is only appropriate for a subset of GCC languages and it is compiling some other language).
Thanks. That's an acceptable workaround, and seems to work as advertised. I may add it to build_adaflags if a central solution won't be accepted.
It would still be better to use parameters only where they are meaningful. Longer command lines make troubleshooting more difficult.
Björn Persson
* Björn Persson:
It would still be better to use parameters only where they are meaningful. Longer command lines make troubleshooting more difficult.
We used to have %{optflags} only, set via the rpmrc dispatch in redhat-rpm-config, and migrating off that to a more flexible solution is under the way. %{optflags} will likely continue including C/C++ specifics, but we'll remove those flags from the flags for the other front ends eventually.
Thanks, Florian