On Fri, Apr 3, 2020 at 8:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> BTW, some of the buildfarm is showing a simpler portability problem:
> they think you were too cavalier about the difference between time_t
> and pg_time_t. (On a platform with 32-bit time_t, that's an actual
> bug, probably.) lapwing is actually failing:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2020-04-03%2021%3A41%3A49
>
> ccache gcc -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla
-Wendif-labels-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g
-O2-Werror -I. -I. -I../../../src/include -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS -D_GNU_SOURCE
-I/usr/include/libxml2 -I/usr/include/et -c -o basebackup.o basebackup.c
> basebackup.c: In function 'AddFileToManifest':
> basebackup.c:1199:10: error: passing argument 1 of 'pg_gmtime' from incompatible pointer type [-Werror]
> In file included from ../../../src/include/access/xlog_internal.h:26:0,
> from basebackup.c:20:
> ../../../src/include/pgtime.h:49:22: note: expected 'const pg_time_t *' but argument is of type 'time_t *'
> cc1: all warnings being treated as errors
> make[3]: *** [basebackup.o] Error 1
>
> but some others are showing it as a warning.
>
> I suppose that judicious s/time_t/pg_time_t/ would fix this.
I think you sent this email just after I pushed
db1531cae00941bfe4f6321fdef1e1ef355b6bed, or maybe after I'd committed
it locally and just before I pushed it. If you prefer a different fix
than what I did there, I can certainly whack it around some more.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company