Opened 2 years ago

Closed 2 years ago

Last modified 10 months ago

#3604 closed defect (fixed)

pgcommon/Makefile.in orders CFLAGS incorrectly leading to wrong liblwgeom.h

Reported by: gdt Owned by: strk
Priority: medium Milestone: PostGIS 2.2.3
Component: build/upgrade/install Version: trunk
Keywords: Cc:

Description

In both libpgcommon and postgis, CFLAGS end up with -I of system libraries before -I../liblwgeom. This causes the installed version of liblwgeom.h to be picked up, instead of the version from the postgis sources, resulting in a build failure.

I have observed the problem on NetBSD 6, and it has also been reported on FreeBSD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211203

The workaround is to remove the installed version.

To fix, adjust CFLAGS/CPPFLAGS so that -I../liblwgeom is before includes of any directory that might have an installed version of postgis (e.g. -I/usr/pkg/include on NetBSD).

Attachments (1)

avoid-installed.patch (2.5 KB) - added by gdt 2 years ago.
patch to avoid installed liblwgeom/ includes

Download all attachments as: .zip

Change History (11)

Changed 2 years ago by gdt

Attachment: avoid-installed.patch added

patch to avoid installed liblwgeom/ includes

comment:1 Changed 2 years ago by gdt

Component: postgisbuild/upgrade/install
Owner: changed from pramsey to strk

comment:2 Changed 2 years ago by gdt

This is harder than it seems. In addition to putting liblwgeom first, pgxs.mk has -I/usr/pkg/include (on pkgsrc systems) in CFLAGS, which is before CPPFLAGS. So the patch also moves the liblwgeom include to CFLAGS via an override. Needs review/discussion.

comment:3 Changed 2 years ago by robe

strk have any input on this. I could just try it and see if it breaks my build and the bot builds.

comment:4 Changed 2 years ago by robe

Resolution: fixed
Status: newclosed

In 15051:

pgcommon/Makefile.in orders CFLAGS incorrectly leading to wrong liblwgeom.h
Patch from Greg Troxel
Closes #3604

comment:5 Changed 23 months ago by robe

In 15130:

pgcommon/Makefile.in orders CFLAGS incorrectly leading to wrong liblwgeom.h
(Fix to use source version instead of installed)
Patch from Greg Troxel
references #3604 for PostGIS 2.2.3

comment:6 Changed 23 months ago by robe

Milestone: PostGIS 2.3.0PostGIS 2.2.3

I was having this issue on FreeBSD because I think the postgis 2.3 liblwgeom I just installed was trying to be used by the 2.2 I was trying to compile.

The error looked like this:

rtpg_geometry.c:105:42: error: too many arguments to function call, expected 2, have 3

        gser = gserialized_from_lwgeom(geom, 0, &gser_size);

               ~~~~~~~~~~~~~~~~~~~~~~~          ^~~~~~~~~~

/usr/local/include/liblwgeom.h:1957:1: note: 'gserialized_from_lwgeom' declared here

extern GSERIALIZED* gserialized_from_lwgeom(LWGEOM *geom, size_t *size);

^

rtpg_geometry.c:184:42: error: too many arguments to function call, expected 2, have 3

        gser = gserialized_from_lwgeom(geom, 0, &gser_size);

               ~~~~~~~~~~~~~~~~~~~~~~~          ^~~~~~~~~~

/usr/local/include/liblwgeom.h:1957:1: note: 'gserialized_from_lwgeom' declared here

extern GSERIALIZED* gserialized_from_lwgeom(LWGEOM *geom, size_t *size);

^

rtpg_geometry.c:326:81: error: too many arguments to function call, expected 2, have 3

                gser = gserialized_from_lwgeom(lwpoly_as_lwgeom(geomval2[call_cntr].geom), 0, &gser_size);

                       ~~~~~~~~~~~~~~~~~~~~~~~                                                ^~~~~~~~~~

/usr/local/include/liblwgeom.h:1957:1: note: 'gserialized_from_lwgeom' declared here

extern GSERIALIZED* gserialized_from_lwgeom(LWGEOM *geom, size_t *size);

^

rtpg_geometry.c:628:59: error: too many arguments to function call, expected 2, have 3

                gser = gserialized_from_lwgeom(pix2[call_cntr].geom, 0, &gser_size);

                       ~~~~~~~~~~~~~~~~~~~~~~~                          ^~~~~~~~~~

/usr/local/include/liblwgeom.h:1957:1: note: 'gserialized_from_lwgeom' declared here

extern GSERIALIZED* gserialized_from_lwgeom(LWGEOM *geom, size_t *size);

^

4 errors generated.

gmake[3]: *** [<builtin>: rtpg_geometry.o] Error 1

gmake[3]: Leaving directory '/usr/home/robe/sources/postgis-2.2.2/raster/rt_pg'

gmake[2]: *** [Makefile:28: pglib] Error 2

gmake[2]: Leaving directory '/usr/home/robe/sources/postgis-2.2.2/raster'

gmake[1]: *** [GNUmakefile:16: all] Error 1

gmake[1]: Leaving directory '/usr/home/robe/sources/postgis-2.2.2'

*** Error code 2

This patch fixed the issue after I committed to 2.2, thanks Greg.

comment:7 Changed 10 months ago by pramsey

I guess it would be too much to hope that you're also the pgSQl packager and could move that -I/usr/pkg/include to CPPFLAGS where it belongs? The result of this change is that the postgis build loses all the flags it should be inheriting from the pgsql build. (The one that gets me is the loss of the -g debug flag, but I'm sure there's others of import).

comment:8 Changed 10 months ago by pramsey

In 16002:

Allow ./configure to set debug flag on module build
that is otherwise over-ridden by pgxs hack
References #3604

comment:9 Changed 10 months ago by strk

Can this be also related to #3037 ?

comment:10 Changed 10 months ago by gdt

No, I am not the pgsql packager. Generally we try to minimally munge upstreams, but I see your point about -I belonging in CPPFLAGS.

I think the real difficulty is making sure includes of files that are in the source tree find those rather than the previous installed version. But perhaps this can be avoided - I'll have a look when I have a chance.

Note: See TracTickets for help on using tickets.