From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add -Wold-style-definition to CFLAGS? |
Date: | 2020-06-09 06:13:35 |
Message-ID: | 20200609061335.q5uaknvgdbrnualc@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-06-09 02:03:09 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > 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.
>
> Ugh. I suspect main() might not be the only problem, either.
There's a few more, but they're far far less noisy. And I don't think
any change the results after the fix, because they don't check for
output on stderr (based on grepping through configure).
> > Upstream autoconf has fixed this in 2014 (1717921a), but since they've
> > not bothered to release since then...
>
> I wonder if there's any way to light a fire under them.
There's been talk about working towards a release a few months back:
https://lists.gnu.org/archive/html/autoconf/2020-03/msg00003.html
> > 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?
>
> I don't really think that -Wold-style-definition is worth that.
Well, we don't need it for that, strictly speaking. Just using
AC_LANG_SOURCE is enough...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-06-09 06:32:24 | Re: Read access for pg_monitor to pg_replication_origin_status view |
Previous Message | Michael Paquier | 2020-06-09 06:11:04 | Re: Read access for pg_monitor to pg_replication_origin_status view |