From Fedora Project Wiki
(Impossible-to-fix packages)
(Recommend to git pull before picking a package to work on)
 
Line 6: Line 6:


<pre>
<pre>
git ls-files logs | sort -R | head -n1
git pull && git ls-files logs | sort -R | head -n1
</pre>
</pre>



Latest revision as of 12:25, 13 January 2023

Procedures for Modern C Porting

Choosing packages to work on

Clone the fedora-modernc-logs repository and pick a log file to work on at random:

git pull && git ls-files logs | sort -R | head -n1

At present, there are so many packages left that this is not likely to create a collision and duplicated work.

Recording work

  • Delete the log file in the fedora-modernc-logs repository.
  • Patches must be upstreamed if there is still an upstream project left. Record a URL for the upstream submission in the patch file or spec file.
  • Add a markdown documentation file to the fedora-modernc repository. Include the Fedora bug if applicable. Always include a link to the Fedora dist-git commit. Please add link titles to external links, especially upstream patch submissions.

Impossible-to-fix packages

Some historic code bases cannot be ported to ISO C or C99 with reasonable effort. It makes sense to build them with -std=gnu89 flag. The instrumented compiler recognizes this and enables support for implicit ints and implicit function declarations.

In a few cases, packages depend on C89-only language features *and* rely C99 inline semantics. The current instrumented compiler cannot handle this. A future opt-out mechanism will support this. At this point, it is recommended to file a bug blocking PortingToModernCExemptions and revisit the package once the opt-out mechanism is available.

Handling false positives

It is important to record exceptions so that further mass-prebuilds with the instrumented compilers do not show the same set of known false positives.

There is currently no way to record exceptions for implicit ints, only for implicit function declarations. The instrumented GCC compiler contains changes that avoid spurious implicit int diagnostics for common erroneous constructs.

Common autoconf issues

Over the years, many C99 compatibility fixes have been applied to the autoconf package, fixing issues in generated configure scripts. It is not always possible to run the autoconf tool during the Fedora build, so patching the generated scripts may be necessary. Some of the standard issues can be patched using this script:

If the generated configure script (or the generated aclocal.m4 file) only contains issues that go away when re-running autoconf (or autoreconf), then there is no need to upstream these changes.

If it is necessary to inhibit running autoconf or automake during the build, use a construct like this in the %prep section after applying the patches:

touch -r aclocal.m4 configure*

Older autoconf versions are available in this COPR repository:

But for anything pre-dating 2.69, it is probably necessary to patch the generated shell code manually because it will be difficult to find a matching autoconf version.