[postgis-tickets] [PostGIS] #3721: PostGIS trunk no longer compiles against PostgreSQL 10 branch

[PostGIS]

#3721: PostGIS trunk no longer compiles against PostgreSQL 10 branch
----------------------+--------------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  blocker  |  Milestone:  PostGIS PostgreSQL
 Component:  postgis  |    Version:  trunk
Resolution:           |   Keywords:  PostgreSQL 10
----------------------+--------------------------------
Description changed by robe:

Old description:

> 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/
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b9d092c962ea3262930e3c31a8c3d79b66ce9d43
>
> {{{
>
> 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.

New description:

 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/

 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b9d092c962ea3262930e3c31a8c3d79b66ce9d43

 {{{

 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.

--

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3721#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.