Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#3274 closed defect (invalid)

PostGIS 2.1 dependency on proj.4

Reported by: watsonta Owned by: pramsey
Priority: high Milestone: PostGIS 2.1.9
Component: postgis Version: 2.1.x
Keywords: proj4 Cc:

Description

Installed PostgreSQL 9.4 w/PostGIS 2.1 alongside 9.1 w/PostGIS 2.0 on RHEL 6.5 to prepare for upgrade. Ran pg_upgrade --check and got library issue: Could not load library "$libdir/postgis-2.0" ERROR: could not load library "/usr/pgsql-9.4/lib/postgis-2.0.so": /usr/pgsql-9.4/lib/postgis-2.0.so: undefined symbol: pj_get_spheroid_defn

With help from strk on "postgresql" IRC channel, we identified the problem as a broken dependency check. PostGIS 2.1 now requires libproj 4.8.0+ (instead of 4.6.0+).

Change History (4)

comment:1 by robe, 9 years ago

watsona -- where did you get your package? This sounds more like a packaging issue than a PostGIS one. PostGIS 2.1 doesn't require 4.8.0 (I've run iton 4.7.1 fine for example), but it looks like PostGIS 2.1 upgrade wiped out the older proj and sadly looks like they are not binary compatible.

Version 0, edited 9 years ago by robe (next)

comment:2 by robe, 9 years ago

nevermind read irc thread - irc thread here for posterity. Though I think it's 4.7+ not 4.8+ and not even sure of that. I just know our bot has been working fine on 4.7 aond postgis 2.1 so.

nhv:	this should help http://gis.stackexchange.com/questions/43370/postgis-error-could-not-load-library-usr-lib-postgresql91-lib64-postgis-2-0-s
20:36:20	sigq:	Title: postgresql - PostGIS ERROR: could not load library "/usr/lib/postgresql91/lib64/postgis-2.0.so" - Geographic Information Systems Stack Exchange (at gis.stackexchange.com)
20:37:12	strk:	ah, >= 4.8
20:37:21	strk:	but... how could his 9.1 install work ?
20:37:43	strk:	watsonta: don't leave us out in the dark, let us know the detail ! :)
20:38:42	watsonta:	Sorry - I just had to install proj and proj-devel. Broken yum dependencies in postgis package.
20:38:51	watsonta:	Now it says that the clusters are compatible
20:39:18	watsonta:	BTW, I'm on RHEL 6.5
20:39:47	watsonta:	<strk> nailed it.
20:40:14	strk:	so you weren't just upgrading postgresql but also changing proj4 version between the two install ?
20:43:04	watsonta:	<strk> no - we were just upgrading from 9.1 to 9.4
20:43:12	watsonta:	<strk> no other changes
20:43:25	strk:	via yum ?
20:43:34	watsonta:	yes - via yum
20:43:52	strk:	well, something must have triggered an upgrade of postgis as well, or a downgrade of proj4
20:44:30	watsonta:	we have to upgrade from postgis 2.0 to 2.1 as there isn't a 2.0 for 9.4
20:44:34	strk:	as if the 9.1 version worked, either there was no need for the 'pj_get_spheroid_defn' symbol (older PostGIS version) or the symbol was included in proj4 library
20:44:49	strk:	a-ha! that's the missing bit of information in your initial report ! :)
20:45:20	watsonta:	and yet, this worked on multiple other environments (dev, qa, test, staging) without this problem
20:46:17		* strk sees that the ./configure script in postgis-2.1 branch does not check for proj-4.8+
20:46:20	strk:	worth a ticket
20:46:21	watsonta:	seems like postgis-2.1 should have a proj-devel as a dependency. it wasn't even installed on this prod box, even though postgis-2.0 worked for 2+ years
20:46:21	strk:	here's what it does:
20:46:25	strk:	dnl Ensure that we are using PROJ >= 4.6.0 (requires pj_set_searchpath)
20:46:27	strk:	if test ! "$POSTGIS_PROJ_VERSION" -ge 46; then AC_MSG_ERROR([PostGIS requires PROJ >= 4.6.0])
20:46:30	strk:	fi
20:46:32	strk:	so builders are not warned about that
20:46:48	strk:	althought good builders would "make check" before distributing a binary...
20:47:00	strk:	watsonta: feel like filing a ticket for this issue ?
20:47:19	strk:	AC_MSG_ERROR([PostGIS requires PROJ >= 4.6.0])
20:47:25	strk:	^^^ even in trunk (to be 2.2.0)
20:47:32	strk:	but truth is we require 4.8.0+ since 2.1.0
20:47:42	watsonta:	just glad it's working now. i will gladly file a ticket - where?
20:47:46	strk:	http://trac.osgeo.org/postgis
20:47:48	sigq:	Title: PostGIS (at trac.osgeo.org)
20:48:10	watsonta:	I'm on it.

comment:3 by strk, 9 years ago

Resolution: invalid
Status: newclosed

Alright, response in code, libpgcommon/lwgeom_transform.c circa line 730:

#if POSTGIS_PROJ_VERSION >= 48
        /* For newer versions of Proj we can pull the spheroid paramaeters and initialize */
        /* using them */
        pj_get_spheroid_defn(pj1, &major_axis, &eccentricity_squared);
        minor_axis = major_axis * sqrt(1-eccentricity_squared);
        spheroid_init(s, major_axis, minor_axis);
#else
        /* For old versions of Proj we cannot lookup the spheroid parameters from the API */
        /* So we use the WGS84 parameters (boo!) */
        spheroid_init(s, WGS84_MAJOR_AXIS, WGS84_MINOR_AXIS);
#endif

So basically PostGIS can work also with older Proj4 versions, but it needs to know at compile time.

It then looks like watsonta's binary was built against Proj 4.8 but was running against a previous version. Very likely a bug in the binary package, or its dependencies (proj-4.8+ being a dependency of the _binary_ postgis as built by the packager).

Feel free to file a separate ticket if you can reproduce the problem by building PostGIS yourself. Thank you.

comment:4 by strk, 9 years ago

reminder: the POSTGIS_PROJ_VERSION macro is determined by macros/ac_proj4_version.m4

Note: See TracTickets for help on using tickets.