Fixing AC_CHECK_DECLS to do the right thing with clang
We've seen repeated complaints about bogus build warnings when using
"clang": it complains that strlcpy and some related library functions
haven't been declared. Several of the buildfarm animals exhibit such
warnings, for instance. That's because Autoconf's AC_CHECK_DECLS macro
fails to cope with the fact that clang only generates a warning, not
an error, for the test case that that macro uses. Noah fixed this
in upstream autoconf several years ago:
http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=82ef7805faffa151e724aa76c245ec590d174580
However, I'm beginning to despair of the Autoconf crowd ever putting
out an official new release. Hence, I propose to apply and back-patch
the attached, which essentially just imports Noah's fix into our
configure script. I've verified that this does the right thing with
Fedora 28's version of clang (clang version 6.0.1).
regards, tom lane
Attachments:
import-autoconf-fix-for-clang.patchtext/x-diff; charset=us-ascii; name=import-autoconf-fix-for-clang.patchDownload+211-3
Hi,
On 2018-11-17 23:32:47 -0500, Tom Lane wrote:
We've seen repeated complaints about bogus build warnings when using
"clang": it complains that strlcpy and some related library functions
haven't been declared. Several of the buildfarm animals exhibit such
warnings, for instance. That's because Autoconf's AC_CHECK_DECLS macro
fails to cope with the fact that clang only generates a warning, not
an error, for the test case that that macro uses. Noah fixed this
in upstream autoconf several years ago:http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=82ef7805faffa151e724aa76c245ec590d174580
However, I'm beginning to despair of the Autoconf crowd ever putting
out an official new release. Hence, I propose to apply and back-patch
the attached, which essentially just imports Noah's fix into our
configure script. I've verified that this does the right thing with
Fedora 28's version of clang (clang version 6.0.1).
Seems like a good plan. The problem doesn't reproduce for me on debian
(using any version of clang), so all I can report is that at patched
build still works as it should.
- Andres
Andres Freund <andres@anarazel.de> writes:
Seems like a good plan. The problem doesn't reproduce for me on debian
(using any version of clang), so all I can report is that at patched
build still works as it should.
Interesting. It's hardly surprising that the problem would occur only
on some platforms, since if <string.h> declares the function then the
problem isn't visible. But I'm surprised that some Debian boxes would
show it and some not. Still, a closer look at the buildfarm shows both
clang-on-Debian members with the warning (eg gull) and clang-on-Debian
members without (eg yours).
regards, tom lane