bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: implicit declaration of function 'utime' in trailing slashes test


From: Tim Rühsen
Subject: Re: implicit declaration of function 'utime' in trailing slashes test
Date: Sat, 23 Jan 2021 19:44:54 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0



On 23.01.21 07:09, Ryan Schmidt wrote:
On Jan 22, 2021, at 16:47, Tim Rühsen wrote:

On 21.01.21 01:34, Ryan Schmidt wrote:
Hi, I'm the maintainer of wget in MacPorts.
In the version of clang included with Xcode 12 and later, implicit declaration 
of functions is an error.
During configure, wget 1.12.1 prints this:
checking whether utime handles trailing slashes on files... no
config.log contains this:
configure:49368: checking whether utime handles trailing slashes on files
configure:49414: ccache /usr/bin/clang -o conftest -DNDEBUG -pipe -Os 
-Werror=implicit-function-declaration -arch x86_64 -I/opt/local/include 
-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c  >&5
conftest.c:491:23: error: implicit declaration of function 'utime' is invalid 
in C99 [-Werror,-Wimplicit-function-declaration]
                  if (!utime ("conftest.tmp/", NULL))
                       ^
1 error generated.
configure:49414: $? = 1
configure: program exited with status 1
So the results of this test don't represent what you want them to.
This configure test uses #include <time.h>. The problem goes away if I change that to 
#include <utime.h>. Then configure output is still:
checking whether utime handles trailing slashes on files... no
but config.log then contains:
configure:49368: checking whether utime handles trailing slashes on files
configure:49414: ccache /usr/bin/clang -o conftest -DNDEBUG -pipe -Os 
-Werror=implicit-function-declaration -arch x86_64 -I/opt/local/include 
-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 conftest.c  >&5
configure:49414: $? = 0
configure:49414: ./conftest
configure:49414: $? = 2
configure: program exited with status 2
Now the results of the test are accurate.
I included this patch in the MacPorts wget 1.12.1 port:
https://github.com/macports/macports-ports/blob/13fd7facb9e1ea9e70b79c8c0b429058b9bb8698/net/wget/files/implicit.patch
Of course you'll want to patch m4/utime.m4 instead of configure.

./configure scripts are not made for using -Werror in CFLAGS.

This is documented somewhere but (sorry), I am just too tired to search for the 
URL right now.

Unfortunately, you no longer have much of a choice. Treating implicit 
declarations of functions as an error is the *default* behavior of the compiler 
included with Xcode 12 and later.

In the output I showed above I have specified 
-Werror=implicit-function-declaration manually in CFLAGS because I am using an 
earlier version of Xcode but I want to simulate the experience of an Xcode 12 
user so that I can identify and fix this type of problem.

Apple intentionally changed the default behavior of the compiler in order to be able to 
ship Macintosh computers with ARM processors ("Apple Silicon"). ARM processors 
have different calling conventions for variadic and non-variadic functions, so the 
compiler must know before you call a function what type of function it is, and the way it 
knows that is by the function declaration.

The C99 standard requires that you declare functions before you use them. It 
has been this way for over 2 decades. wget should do so in all of its code, 
regardless of whether the code is in a configure test or elsewhere.

This one configure test that I mentioned is the only place where I noticed a 
problem, so as far as I know only the one-byte change I proposed above needs to 
be made.

Thanks for the explanation, that makes it clearer now (and possibly my brain is not as mushed as during my last read/answer).

The code involved here comes directly from gnulib and is not part of the wget project. The issue affects not only wget and any patching here is mostly lost time/efford.

So I am adding the gnulib mailing list to the recipients as IMO this issue should be discussed/answered there. It will be read by people with more related expertise than I can provide.

Regards, Tim

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]