Hi,
On 2020-05-09 19:11:56 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2020-05-09 14:15:01 -0400, Tom Lane wrote:
> >> Andres Freund <andres@anarazel.de> writes:
> >>> Since gcc has a warning detecting such definition, I think we ought to
> >>> automatically add it when available?
>
> >> +1
>
> > Any opinion about waiting for branching or not?
>
> I'd be OK with pushing it now, but I dunno about other people.
I did run into a small bit of trouble doing so. Those seem to make it a
mistake to target 13.
Unfortunately it turns out that our CFLAG configure tests don't reliably
work with -Wold-style-definition. The problem is that the generated
program contains 'int main() {...}', which obviously is an old-style
definition. Which then causes a warning, which in turn causes the cflag
tests to fail because we run them with ac_c_werror_flag=yes.
There's a pretty easy local fix, which is that we can just use
AC_LANG_SOURCE() instead of AC_LANG_PROGRAM()
PGAC_PROG_VARCC_VARFLAGS_OPT(). There seems to be little reason not to
do so.
But that still leaves us with a lot of unnecessary subsequent warnings
for other tests in config.log. They don't cause problems afaics, as
ac_c_werror_flag=yes isn't widely used, but it's still more noisy than
I'd like. And the likelihood of silent failures down the line seems
higher than I'd like.
Upstream autoconf has fixed this in 2014 (1717921a), but since they've
not bothered to release since then...
The easiest way that I can see to deal with that is to simply redefine
the relevant autoconf macro. For me that solves the vast majority of
these bleats in config.log. That's not particularly pretty, but we have
precedent for it... Since it's just 16 lines, I think we can live with
that?
Comments?
Greetings,
Andres Freund