Thread: pgsql: Fix compiler warning for ppoll() on Cygwin
Fix compiler warning for ppoll() on Cygwin _GNU_SOURCE is required to get the prototype, so just define that globally, as was already done in the linux template. Discussion: https://www.postgresql.org/message-id/flat/6b467edc-4018-521f-ab18-171f098557ca%402ndquadrant.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/127ccb37251744c0fad2df0f3f67dd2c38fe8389 Modified Files -------------- src/template/cygwin | 3 +++ 1 file changed, 3 insertions(+)
Peter Eisentraut <peter@eisentraut.org> writes: > Fix compiler warning for ppoll() on Cygwin > _GNU_SOURCE is required to get the prototype, so just define that > globally, as was already done in the linux template. This seems to have broken lorikeet: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2019-12-23%2006%3A38%3A29 ================== pgsql.build/src/test/regress/regression.diffs =================== diff -U3 /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/expected/create_function_1.out /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/results/create_function_1.out --- /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/expected/create_function_1.out 2019-12-23 01:54:52.899453200-0500 +++ /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/results/create_function_1.out 2019-12-23 01:55:58.318974000-0500 @@ -90,7 +90,7 @@ ERROR: only one AS item needed for language "sql" CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C AS 'nosuchfile'; -ERROR: could not access file "nosuchfile": No such file or directory +ERROR: could not access file "nosuchfile": ENOENT CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C AS '/home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/regress.dll', 'nosuchsymbol'; ERROR: could not find function "nosuchsymbol" in file "/home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/regress.dll" I'm guessing that this broke something in the #ifdef nest in gnuish_strerror_r(), causing it to fail, causing pg_strerror_r() to fall back to using get_errno_symbol(). regards, tom lane
I think the config.cache of lorikeet needs to be cleaned, because the return type of strerror_r() has changed as a result of this commit, but the build farm logs still show the old test result being used from the cache. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services On 2019-12-25 07:17, Tom Lane wrote: > Peter Eisentraut <peter@eisentraut.org> writes: >> Fix compiler warning for ppoll() on Cygwin >> _GNU_SOURCE is required to get the prototype, so just define that >> globally, as was already done in the linux template. > > This seems to have broken lorikeet: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2019-12-23%2006%3A38%3A29 > > ================== pgsql.build/src/test/regress/regression.diffs =================== > diff -U3 /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/expected/create_function_1.out /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/results/create_function_1.out > --- /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/expected/create_function_1.out 2019-12-23 01:54:52.899453200-0500 > +++ /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/results/create_function_1.out 2019-12-23 01:55:58.318974000-0500 > @@ -90,7 +90,7 @@ > ERROR: only one AS item needed for language "sql" > CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C > AS 'nosuchfile'; > -ERROR: could not access file "nosuchfile": No such file or directory > +ERROR: could not access file "nosuchfile": ENOENT > CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C > AS '/home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/regress.dll', 'nosuchsymbol'; > ERROR: could not find function "nosuchsymbol" in file "/home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/regress.dll" > > I'm guessing that this broke something in the #ifdef nest in > gnuish_strerror_r(), causing it to fail, causing pg_strerror_r() > to fall back to using get_errno_symbol(). > > regards, tom lane >
On Thu, Dec 26, 2019 at 7:28 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
I think the config.cache of lorikeet needs to be cleaned, because the
return type of strerror_r() has changed as a result of this commit, but
the build farm logs still show the old test result being used from the
cache.
I'll see what I can do. Connecting to it remotely (from Australia) is a fun exercise ...
cheers
andrew
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I think the config.cache of lorikeet needs to be cleaned, because the
> return type of strerror_r() has changed as a result of this commit, but
> the build farm logs still show the old test result being used from the
> cache.
lorikeet's latest build run appears to have been done without config
cache, and it succeeded, so your guess was correct.
Next question is why the buildfarm client got that wrong. Seems like
its accache logic needs to notice changes in src/template/* as well as
the configure script proper.
regards, tom lane
On Thu, Dec 26, 2019 at 4:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I think the config.cache of lorikeet needs to be cleaned, because the
> return type of strerror_r() has changed as a result of this commit, but
> the build farm logs still show the old test result being used from the
> cache.
lorikeet's latest build run appears to have been done without config
cache, and it succeeded, so your guess was correct.
Next question is why the buildfarm client got that wrong. Seems like
its accache logic needs to notice changes in src/template/* as well as
the configure script proper.
The problem with that is that a change in one template will cause the cache to be invalidated for every buildfarm member. Maybe that doesn't matter too much - after all we used not to keep the cache at all.
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On Thu, Dec 26, 2019 at 4:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Next question is why the buildfarm client got that wrong. Seems like
>> its accache logic needs to notice changes in src/template/* as well as
>> the configure script proper.
> The problem with that is that a change in one template will cause the cache
> to be invalidated for every buildfarm member. Maybe that doesn't matter too
> much - after all we used not to keep the cache at all.
I don't think we change those templates often enough for that to be
much of a concern. Trying to make the buildfarm script smart enough
to check only the relevant template seems like more trouble than it'd
be worth.
regards, tom lane
On Fri, Dec 27, 2019 at 10:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andrew Dunstan <andrew@dunslane.net> writes: > > On Thu, Dec 26, 2019 at 4:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Next question is why the buildfarm client got that wrong. Seems like > >> its accache logic needs to notice changes in src/template/* as well as > >> the configure script proper. > > > The problem with that is that a change in one template will cause the cache > > to be invalidated for every buildfarm member. Maybe that doesn't matter too > > much - after all we used not to keep the cache at all. > > I don't think we change those templates often enough for that to be > much of a concern. Trying to make the buildfarm script smart enough > to check only the relevant template seems like more trouble than it'd > be worth. > Right, fix along these lines committed, will be in the next release. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services