To be clear, I do not ask that this ticket be fixed in S2_6 or S3_0. I believe that it is enough to consider it for fixing in the main branch, to get released in the more distant future.
Well, this sort of works as intendet. When at_quick_exit() isn't declared in <stdlib.h>, this compile (+link) test fails indicating that the at_quick_exit() isn't available. I hope your whitelisting does not change that (well, the linking step should fail in any case).
But I guess the problem is in that "elevated -Wimplicit-function-declaration errors to the *user's attention*." So configure checks relying on getting implicit-function-declaration error as means to detecting if a function is declared are problematic. I think we have more of those, though not necessarily ones that are supposed to fail on macOS.
To clarify, the whitelisting by MacPorts has no effect on the compile (+link) test of at_quick_exit(). The whitelist just tells MacPorts to drop at_quick_exit() from the list of -Wimplicit-function-declaration errors which it elevates to the user's attention.
Yes, a good long-term response to this ticket would be to look for any configure checks which rely on getting an implicit-function-declaration error as means to detecting if a function is declared, and find a different way to perform that check. Ideally, it will be a way which relies on code running but reporting the correct information about what features are not supported, instead of relying on code which fails to compile or link or run in order to signal features which are not supported.
Any test that can be done some other way, should not rely on running the code - we can't run it when cross-compiling, so would be forced always to make pessimistic assumptions.
Reply To cazfi
we can't run it when cross-compiling, so would be forced always to make pessimistic assumptions.
Actually, we could still have the current checks as the fallback to be used in case of cross-compiling. So there would be no regression in cross-compile support, but still an improvement to native build.
All this is about autotools build. I have not considered what's the situation with the meson based build.
A configuration macro checks for C11 language feature at_quick_exit() by creating a simple C program which, when compiled on macOS via MacPorts, causes an undesirable -Wimplicit-function-declaration error. This is acceptable, but not ideal. It would be better for macOS and the macPorts distribution if the configuration macro used feature testing like __has_builtin instead.
The macro causing the error is FC_C11_AT_QUICK_EXIT, in m4/c11.m4:32-51. It tests for a C2011 language standard feature by checking for the existence of an at_quick_exit() function. The specific Autoconf macros running the test are AC_LINK_IFELSE and AC_LANG_PROGRAM. The test program expands to:
#include <stdlib.h> static void func(void) {} int main (void) { at_quick_exit(func); ; return 0; }Note that this code does #include <stdlib.h>, the file which should declare at_quick_exit() . Thus the test code tries to have explicit, not implicit, function declaration. However, the compiler (and/or the corresponding macOS SDK) does not support the feature, so that version of stdlib.h does not declare the function. The result is that the compiler thinks the program is implicitly defining the function. It raises a -Wimplicit-function-declaration warning.
-Wimplicit-function-declaration warnings are undesirable when compiling Freeciv on macOS. macOS's Xcode compilers (based on clang) have applied -Werror and -Wimplicit-function-declaration options since about 2019. They do this as part of support for the Apple ARM architecture CPUs. On those CPUs, the calling sequence for varargs functions differ from the calling sequence for functions with a fixed number of parameters. If a function prototype is not declared, the compiler is unable to guess which kind of args the function uses. Also, defining functions without explicitly declaring them has been illegal C language since about the late 1980s, but many compilers have tolerated it. Thus, compiler errors have not been a reason to clean up these macros — until now. For more on the Xcode compiler issue, see the writeup in the MacPorts wiki at https://trac.macports.org/wiki/WimplicitFunctionDeclaration .
Since 2021, the MacPorts distribution software has specifically elevated -Wimplicit-function-declaration errors to the user's attention. However, MacPorts has a whitelist mechanism for functions which are not supported on certain macOS versions. The function used in Freeciv, at_quick_exit(), is now on that whitelist. See MacPorts ticket #64550 freeciv @2.6.6: at_quick_exit gives -Wimplicit-function-declaration warning, false positive. Thus for now, this configuration macro is not a problem for Freeciv in MacPorts. In the long term, however, it would be helpful if Freeciv could change the configuration macro so that it does not cause a -Wimplicit-function-declaration error.
What would be a better alternative? For clang version 11 and later, one alternative is to use the extensions which the compiler provides for testing which features are available. For example, __has_builtin. I have not investigated if gcc has a similar extension, nor how to reconcile that kind of a feature test with what Autoconf offers, and what older compilers support.
Another occurrence of a -Wimplicit-function-declaration, generated by Freeciv's configuration scripts, comes from missing #includes. That was the subject of #43737. It has been fixed.