port maintainers: please test check for implicit decls

[Ryan Schmidt]

On Nov 24, 2020, at 16:15, Clemens Lang wrote:

> This will become a significant problem with the release of Big Sur,
> since Apple has made -Wimplicit-function-declaration an error by default
> due to details of the calling convention on Apple Silicon.

Thanks Clemens. I've been meaning to write about that problem here. I want to elaborate on this issue for our developers who haven't been following it closely.

It's the version of clang shipped with Xcode 12 that introduced the change that made implicit declaration of functions an error rather than a warning, so it also affects Catalina users who have upgraded to Xcode 12 (or the matching CLT). It does not affect our Catalina buildbot worker because I'm keeping it at Xcode 11.x (with the matching CLT).

There are a zillion ports affected by this issue, so we have a lot of work to do to fix them all, and we appreciate all developers who have time to pitch in and fix ports. There's often a tendency for developers to stick to the ports they know and maintain and to ignore tickets about other ports, but with this problem the needed fixes are often pretty similar so once you understand how to fix it once or twice, you can apply that knowledge to fix other ports even if you're not familiar with those ports.

Before trying to patch the problem yourself, check if there's a new version of the software available. Maybe updating the port would fix it. If no new version is available, it can also be worthwhile to see if Debian or another package management system out there has already developed patches that we could use. If you do have to develop a patch yourself, and the software is still being actively developed, you should usually send the patch back to the developers so they can include it in the next version. Add the URL of your bug report to the header of your patch.

The way to fix the problem is usually to include the right headers. Often clang will tell you in the error message what the right header is. If it doesn't, you can look up the function in the manpages using "man 3" or "man 2". For example "man 3 exit" tells you that to use "exit" you need to "#include <stdlib.h>".

There are four ways that this problem typically manifests. First, a port could fail to build in the build phase with an error about implicit function declarations. This is straightforward; you would usually fix the file mentioned in the error. Second, a port could fail in the configure phase because one of the configure tests failed to find something essential because of implicit function declarations in that specific test in the configure script. This is more difficult because MacPorts 2.6.4 and earlier don't show you the error in the main log; you have to look in the config.log. This is the problem that this change from Clemens is designed to address, by looking through config.log for you and pulling relevant errors into the main log. To fix the problem, if your port does not auto(re)conf, patch the configure script tests. If your port does auto(re)conf, patch the tests in their original files (configure.ac/configure.in/any .m4 file, possibly even one installed by another port). A third possibility is that a configure test could get the wrong result due to implicit function declaration but allow configure to succeed, and then the build fails later with any number of unexpected errors. The fourth way is like the third expect that the build succeeds but is built wrong due to wrong configure results; in this case, in addition to fixing the problem, the revision would need to be increased to rebuild it.

There are two possible fixes for implicit declaration of function "exit", and this is a common error because so many configure script tests use it without including the required header. One possible fix is to add "#include <stdlib.h>". The other possible fix, provided that "exit" is being called from "main", is to replace "exit(...)" with "return ...".

Please resist the urge to simply add -Wno-error=implicit-function-declaration to CFLAGS. This returns you to the way that Xcode 11 and earlier worked and while it may allow the build to succeed on x86_64, the build could either fail on arm64 or worse yet succeed but crash at runtime. Apple made this condition an error for a reason: the compiler needs to know whether a function is variadic or non-variadic in order to know how to generate the correct machine code to call the function on arm64, and the way that the compiler knows that is by seeing a function declaration or definition before the function is called. In other words, include the header that contains the declaration.

You can find many of the tickets about ports that need fixing by searching the issue tracker for summary "implicit":

https://trac.macports.org/query?status=!closed&summary=~implicit

If you need examples of how to fix these kinds of problems you can search commits for "implicit":

https://github.com/macports/macports-ports/search?q=implicit&type=commits

We often name the patchfile "implicit.patch" to make it easier to find so you can also search your local ports tree for files of that name. We often put the exact error messages that were encountered that the patch fixes in the header of the patchfile to make it easier for others to find when trying to figure out how to fix these errors.


If you want to participate in experiencing and fixing these problems but you haven't upgraded to Xcode 12, you can fake it by modifying portconfigure.tcl:

--- src/port1.0/portconfigure.tcl.orig
+++ src/port1.0/portconfigure.tcl
         configure.classpath
 # compiler flags section
 default configure.optflags      -Os
-default configure.cflags        {${configure.optflags}}
-default configure.objcflags     {${configure.optflags}}
+default configure.cflags        {${configure.optflags} -Werror=implicit-function-declaration}
+default configure.objcflags     {${configure.optflags} -Werror=implicit-function-declaration}
 default configure.cppflags      {[portconfigure::configure_get_cppflags]}
 proc portconfigure::configure_get_cppflags {} {
     global prefix

This is what I'm doing on High Sierra. Note that this will only be accurate for ports that actually honor MacPorts CFLAGS, but if you encounter a port that does not, that is in and of itself a bug that should be fixed.