To help me find bugs in a range of projects, I have a wrapper around gcc
that forces -Werror -pedantic.
I expect to get a lot of errors during builds - that's the point - but what
I didn't expect was for autoconf to be broken.

The main problem is that autoconf fails to recognize a range of standard
functions, such as isblank and strpbrk.
This in turn leads projects to define their own replacements for things
that are not actually missing, and some of those replacements outright
break the compilation.

I know that autoconf is a separate project from Bash, but Bash is certainly
affected by this; for example, when HAVE_STRPBRK and HAVE_ISBLANK are
(wrongly) undefined:


> *gcc  -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"x86_64"'
> -DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"x86_64-pc-linux-gnu"'
> -DCONF_VENDOR='"pc"'
> -DLOCALEDIR='"/tmp/bash/204382fb58575fcd0479b30547d30ec6a9d307ab/share/locale"'
> -DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H -DDEBUG -DMALLOC_DEBUG -I.  -I.
> -I./include -I./lib  -Wno-parentheses -Wno-format-security   -g -O2 -c
> pcomplete.c*In file included from shell.h:28,
>                  from pcomplete.c:46:
> /usr/include/ctype.h:130:1: error: expected identifier or ‘(’ before ‘int’
>   130 | __exctype (isblank);
>       | ^~~~~~~~~
> syntax.h:103:30: error: expected ‘)’ before ‘==’ token
>   103 | #  define isblank(x)    ((x) == ' ' || (x) == '\t')
>       |                              ^~
> pcomplete.c:78:14: error: conflicting types for ‘strpbrk’; have ‘char
> *(char *, char *)’
>    78 | extern char *strpbrk (char *, char *);
>       |              ^~~~~~~
> In file included from bashansi.h:25,
>                  from pcomplete.c:39:
> /usr/include/string.h:323:14: note: previous declaration of ‘strpbrk’
> with type ‘char *(const char *, const char *)’
>   323 | extern char *strpbrk (const char *__s, const char *__accept)
>       |              ^~~~~~~


A significant source of detection failures is that the probes assume that
K&R function declarations (without parameters) are still valid. (Bzzzt!
Nope.)

configure:13875: checking for isblank
> configure:13875: gcc -o conftest -g -O2   conftest.c  >&5
> conftest.c:262:6: error: conflicting types for built-in function
> 'isblank'; expected 'int(int)' [-Werror=builtin-declaration-mismatch]
>   262 | char isblank ();
>       |      ^~~~~~~
> conftest.c:250:1: note: 'isblank' is declared in header '<ctype.h>'


At this point I'm beginning to question the value of autoconf for "general
use". I'm sure it's still useful for corner cases, but it was conceived for
a different world, and assumptions made back then have become problems now.

And it's SLOW. On my fairly old computer, autoconf is a major choke point
for builds: it takes around 20 seconds, while the entirety of the rest of
the build takes about 22 seconds. On newer systems (with more cores) it
probably *exceeds* the time taken by the rest of the build. Are there any
plans to improve autoconf? Or replace it? Perhaps we could have a
supplementary config system that assumes full C99/07/11/17/23 and POSIX
compliance, and just allows tweaking compiler options and build paths?

-Martin

PS:

*autoconf --version*
> autoconf (GNU Autoconf) 2.71
> Copyright (C) 2021 Free Software Foundation, Inc.

[snip]

> *type -ap gcc | sed "s#$HOME/#~/#"*
> ~/sbin/gcc
> /usr/bin/gcc


*cat ~/sbin/gcc*
> #!/bin/sh
> exec /usr/bin/*gcc* *-Werror -pedantic* -Wno-parentheses
> -Wno-stringop-truncation -Wno-format-truncation "$@"
>

*gcc --version*
> gcc (Debian 12.2.0-14+deb12u1) 12.2.0
> Copyright (C) 2022 Free Software Foundation, Inc.

[snip]

Reply via email to