Opened 8 years ago
Closed 8 years ago
#3721 closed defect (fixed)
PostGIS trunk no longer compiles against PostgreSQL 10 branch
Reported by: | robe | Owned by: | robe |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 2.4.0 |
Component: | postgis | Version: | master |
Keywords: | PostgreSQL 10 | Cc: |
Description (last modified by )
Hmm I just looked at latest PostgreSQL 10.0 regress on debbie, and it's pretty ugly. Doesn't even make it past compile.
make[1]: Entering directory '/var/lib/jenkins/workspace/postgis/regress_pgdev/branches/2.4/libpgcommon' gcc -I../liblwgeom -g -O2 -I/var/lib/jenkins/workspace/pg/rel/pg10.0w64/include/postgresql/server -fPIC -DPIC -Wall -Wmissing-prototypes -c -o gserialized_gist.o gserialized_gist.c In file included from gserialized_gist.c:23:0: gserialized_gist.c: In function ‘gidx_from_gbox_p’: gserialized_gist.c:98:25: error: ‘FLT_MAX’ undeclared (first use in this function) GIDX_SET_MIN(a,2,-1*FLT_MAX); ^ gserialized_gist.h:84:75: note: in definition of macro ‘GIDX_SET_MIN’ #define GIDX_SET_MIN(gidx, dimension, value) ((gidx)->c[2*(dimension)] = (value)) ^ gserialized_gist.c:98:25: note: each undeclared identifier is reported only once for each function it appears in GIDX_SET_MIN(a,2,-1*FLT_MAX); ^ gserialized_gist.h:84:75: note: in definition of macro ‘GIDX_SET_MIN’ #define GIDX_SET_MIN(gidx, dimension, value) ((gidx)->c[2*(dimension)] = (value)) ^ gserialized_gist.c: In function ‘gserialized_datum_get_gidx_p’: gserialized_gist.c:277:27: error: ‘FLT_MAX’ undeclared (first use in this function) GIDX_SET_MIN(gidx,2,-1*FLT_MAX); ^ gserialized_gist.h:84:75: note: in definition of macro ‘GIDX_SET_MIN’ #define GIDX_SET_MIN(gidx, dimension, value) ((gidx)->c[2*(dimension)] = (value))
Looks like this may be result of change in PostgreSQL 10.0. As best as I can guess from tracing first occurence of failure.
The smoking gun is this: http://debbie.postgis.net:8080/job/PG_Version_Dev_Git/2006/
Changes Remove now-dead code for !HAVE_INT64_TIMESTAMP. (details) Commit b9d092c962ea3262930e3c31a8c3d79b66ce9d43 by Tom Lane Remove now-dead code for !HAVE_INT64_TIMESTAMP. This is a basically mechanical removal of #ifdef HAVE_INT64_TIMESTAMP tests and the negative-case controlled code. Discussion: https://postgr.es/m/26788.1487455319@sss.pgh.pa.us
or this one: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c29aff959dc64f7321062e7f33d8c6ec23db53d3
http://debbie.postgis.net:8080/job/PG_Version_Dev_Git/2007/changes#detail0 Commit c29aff959dc64f7321062e7f33d8c6ec23db53d3 by Tom Lane Consistently declare timestamp variables as TimestampTz. Twiddle the replication-related code so that its timestamp variables are declared TimestampTz, rather than the uninformative "int64" that was previously used for meant-to-be-always-integer timestamps. This resolves the int64-vs-TimestampTz declaration inconsistencies introduced by commit 7c030783a, though in the opposite direction to what was originally suggested. This required including datatype/timestamp.h in a couple more places than before. I decided it would be a good idea to slim down that header by not having it pull in <float.h> etc, as those headers are no longer at all relevant to its purpose. Unsurprisingly, a small number of .c files turn out to have been depending on those inclusions, so add them back in the .c files as needed. Discussion: https://postgr.es/m/26788.1487455319@sss.pgh.pa.us Discussion: https://postgr.es/m/27694.1487456324@sss.pgh.pa.us
Though I may have missed something since remove date specific code I don't see how that could affect us unless if something unintended was removed.
Change History (5)
comment:1 by , 8 years ago
Description: | modified (diff) |
---|
comment:2 by , 8 years ago
comment:3 by , 8 years ago
Milestone: | PostGIS PostgreSQL → PostGIS 2.4.0 |
---|
comment:4 by , 8 years ago
Owner: | changed from | to
---|
ahah I think the key words are:
we must have been relying on that include