On 29.07.25 11:46, David Rowley wrote:
../src/backend/parser/gram.y:19362:12: error: call to undeclared
function 'typeof'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
19362 | result = copyObject(p->argType);
It's not quite clear to me why the C11 test passes but then the build
fails. I assumed the mixed -std=gnu11 then -std=c99 are passed in the
test as well. I don't know how to check.
The equivalent of config.log is in build/meson-logs/meson-log.txt.
Strangely, if I swap the order of the c11_test_args so the test tries
and uses -std=c11 first, it works ok.
@@ -558,7 +558,7 @@ if not cc.compiles(c11_test, name: 'C11')
if cc.get_id() == 'msvc'
c11_test_args = ['/std:c11']
else
- c11_test_args = ['-std=gnu11', '-std=c11']
+ c11_test_args = ['-std=c11', '-std=gnu11']
endif
The situation is that with my original code, the C11 test picks the
option -std=gnu11, and the typeof() test is then run with
cc ... -std=c99 ... -std=gnu11
which makes the test for typeof() pass (last option wins), but the
actual build is run with
cc ... -std=gnu11 ... -std=c99
which disables the availability of typeof(), but pg_config.h says it's
available, so the compilation fails.
If you flip the order of the arguments to be tested, then the C11 test
picks -std=c11, and the typeof() test runs with
cc ... -std=c99 ... -std=c11
which will fail to detect typeof() (since it's neither in strict C99 nor
in strict C11), and then later the actual compilation won't see typeof()
at all.
Ideally, the tests should be run with the arguments in the same order as
the actual compilation, but I don't think meson is equipped to support
that. I've been digging around the code and the documentation and don't
find any mention about the *order* of the arguments supplied by various
means like global, project, per-target, tests, environment, etc. So I
don't think there is any hope right now to sanely support "competing"
arguments supplied from different sources.
(One might have valid concerns about -I and -L options, but that's a
different potential topic.)
But since this is not how the patch was supposed to be used anyway, this
shouldn't be a problem in practice. It's not a new problem anyway.
FWIW, if you do this with autoconf, you get an early failure:
./configure CFLAGS='-std=c90'
...
checking for gcc option to accept ISO C89... none needed
checking for gcc option to accept ISO C99... unsupported
configure: error: C compiler "gcc" does not support C99
So putting "-std=" options into CFLAGS was never working.
