Ticket #43737

Configure scripts give needless -Wimplicit-function-declaration errors on macOS

Open Date: 2022-01-29 18:15 Last Update: 2022-02-07 21:04

Reporter:
Owner:
Type:
Status:
Closed
Component:
MileStone:
Priority:
5 - Medium
Severity:
5 - Medium
Resolution:
Fixed
File:
2

Details

Three configuration macros create simple C programs which, when compiled on macOS, needlessly cause -Wimplicit-function-declaration errors. Adding #include <stdlib.h> and #include <stdlib.h> to those macros prevents those warnings, without changing what the configuration macros are trying to check for.

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. This means that the programs generated by the configuration macros may, on macOS, fail to compile, instead of compiling and running. This means in turn that the macros may get the wrong result about the system's capabilities, and so they may configure Freeciv incorrectly. 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. As an interim measure, the MacPorts distribution can patch Freeciv to prevent these errors. See MacPorts ticket #64551 freeciv @2.6.6: X11 config tests gives -Wimplicit-function-declaration warning on exit, strcmp. In the long term, it helps MacPorts to distribute Freeciv if Freeciv can prevent these warnings upstream from MacPorts.

The fix for all but one of these errors is simple: patch m4/x.m4 to add one line in each of two places, and patch m4/vsnprintf.m4 to add two lines in one place. I will attach patches to this ticket, which I have tested on the S2_6 branch, version 2.6.6 code. I will also test against the other branches, and produce different patches for those branches if necessary.

Another occurrence of a -Wimplicit-function-declaration, generated by Freeciv's configuration scripts, comes from a check on c11 functionality. It is not a matter of a missing #include. This will be the subject of a separate ticket.

Ticket History (3/12 Histories)

2022-01-29 18:15 Updated by: jdlh
  • New Ticket "Configure scripts give needless -Wimplicit-function-declaration errors on macOS" created
2022-01-29 18:59 Updated by: cazfi
Comment

Ok, so I assume these particular configure checks get run before our configure sets -Wimplicit-function-declaration itself, and have thus avoided getting caught when the option is not on by default.

From the MacPorts ticket it seems that two of the occurrences are from x11 configure checks, needed for xaw-client support in freeciv-2.6 and earlier. As xaw-client has been dropped from freeciv-3.0, I think these are already gone. This leaves one occurrence in vsnprintf.m4.

2022-01-29 19:51 Updated by: cazfi
Comment

Trying to figure out if we should still try to get fix for this to 3.0.0, as a freeze exception.

Reply To jdlh

macOS's Xcode compilers (based on clang) have applied -Werror and -Wimplicit-function-declaration options since about 2019.

Does the '-Werror' here mean that the issue is an hard error, completely preventing freeciv compilation on MaxPorts? Ticket subject too seems to indicate an error, rather than warning.

Another occurrence of a -Wimplicit-function-declaration, generated by Freeciv's configuration scripts, comes from a check on c11 functionality. It is not a matter of a missing #include. This will be the subject of a separate ticket.

Does this mean that fixing this ticket alone would not make freeciv compilable on MacPorts, but also that future(?) ticket needs to be fixed to actually achieve anything making it worth freeze exception?

2022-01-29 22:25 Updated by: cazfi
Comment

Reply To cazfi

Trying to figure out if we should still try to get fix for this to 3.0.0, as a freeze exception. Reply To jdlh

macOS's Xcode compilers (based on clang) have applied -Werror and -Wimplicit-function-declaration options since about 2019.

Does the '-Werror' here mean that the issue is an hard error, completely preventing freeciv compilation on MaxPorts?

Answering myself: It just causes configure check to fail, giving an indication that system vsnprintf() has issues -> fallback will be used instead. So things should still work in the end -> not critical.

2022-01-30 06:01 Updated by: jdlh
Comment

Does the '-Werror' here mean that the issue is an hard error…?

Yes. The compilation of the configure check fails with an error. The compiler issues a -Wimplicit-function-declaration warning, then escalates it to an error.

…completely preventing freeciv compilation on MaxPorts?

No. The errors occur in small test programs generated by the configuration script. So, configuration checks fail when maybe the correct outcome is that they succeed. I don't know whether the resulting configuration is correct anyway, or is wrong. Freeciv itself still compiles and runs on macOS (on my compiler and SDK version at least). It might have the wrong configuration, but Freeciv (2.6.6 at least) still compiles and runs.

Does this mean that fixing this ticket alone would not make freeciv compilable on MacPorts, but also that future(?) ticket needs to be fixed to actually achieve anything making it worth freeze exception?

Neither a fix to this ticket nor to the other ticket is necessary to make Freeciv compilable on MacPorts. I can patch the Freeciv code within MacPorts to fix this ticket. The other ticket is about a configure check which fails correctly, and MacPorts will suppress the error message.

So neither ticket justifies a freeze exception to 3.0.0 in my humble opinion.

In a little while, I hope to check all the other branches (master, S3_1, S3_0) for this ticket, and to file the other ticket. That will make the situation a little clearer.

Thank you for your prompt attention, caszfi!

2022-01-30 17:23 Updated by: jdlh
Comment

I have looked at this issue in branches master, S3_1, and S3_0. In all of those branches, file m4/x.m4 is no longer present, so does not need to be patched. And, file m4/vsnprintf.m4 appears to be identical in all these branches and in S2_6, so the patch that fixes this file for S2_6 works just as well in the other three branches.

I have attached a patch, 0002-Eliminate-needless-Wimplicit-function-declaration-er.patch . It patches m4/vsnprintf.m4 only. I believe that this patch, applied to any of branches master, S3_1, or S3_0, will fix the problem described by this ticket.

Here is more detail on what the patch 0002 does. I reconfigured the project in branch master. There were three occurrences of -Wimplicit-function-declaration in the config.log file. The first is related to function at_quick_exit, and is the subject of the other ticket I have alluded to above. The other two occurrences are related to this ticket, and are the following:

configure:38800: checking for working vsnprintf
configure:38856: /usr/bin/clang -o conftest -g -O2 -I/opt/local/include -DLOCALEDIR="\"${datarootdir}/locale\"" -DBINDIR="\"${exec_prefix}/bin\"" 
        -L/opt/local/libexec/qt5/lib -L/opt/local/lib conftest.c -liconv -pthread >&5
conftest.c:183:5: warning: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Wimplicit-function-declaration]
    exit(1);
    ^
conftest.c:183:5: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
conftest.c:192:7: warning: implicitly declaring library function 'strcmp' with type 'int (const char *, const char *)' [-Wimplicit-function-declaration]
  if (strcmp(buffer, "1234"))
      ^
conftest.c:192:7: note: include the header <string.h> or explicitly provide a declaration for 'strcmp'
2 warnings generated.
configure:38856: $? = 0
configure:38856: ./conftest
configure:38856: $? = 0
configure:38867: result: yes

These errors arise when the script in m4/vsnprintf.m4 compiling its configuration check program. The program lacks #include <stdlib.h>, so the function exit() is not declared. It also lacks #include <string.h>, so the function strcmp() is not declared. This patch adds these two #includes to the script, so that they are in the configure check program. With the patch applied, reconfigure the project. Now the lines labelled conftest.c:183:5 and conftest.c:192:7 no longer appear in config.log.

I suggest definitely applying this patch to master, S3_1, and S2_6. I don't think it needs to be a freeze exception for S3_0. Once Freeciv 3.0.0 is released, then apply the patch to S3_0 so that it appears in Freeciv 3.0.1.

I will apply the equivalent of patch 0001 to freeciv 2.6.6 via MacPorts mechanisms, and the equivalent of patch 0002 to freeciv 3.0.0 when it ships. Freeciv will compile and run fine in MacPorts if we apply these patches at the MacPorts level. However, in the long run it would be better to fix these configuration scripts upstream.

2022-02-05 15:13 Updated by: cazfi
  • Owner Update from (None) to cazfi
  • Severity Update from 4 to 5 - Medium
2022-02-05 16:12 Updated by: cazfi
  • Resolution Update from None to Accepted
2022-02-06 06:08 Updated by: cazfi
Comment

We are releasing RC2, and still to get this to 3.0.0 as part of it.

2022-02-07 21:04 Updated by: cazfi
  • Status Update from Open to Closed
  • Resolution Update from Accepted to Fixed

Attachment File List

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login