Thread: Re: [PostgreSQL YUM Repository - Bug #3710] (Resolved) RHEL7postgresql11 postgis2.5 fails with /usr/pgsql-11/lib/postgis-2.5.so:undefined symbol: geod_polygon_init
Re: [PostgreSQL YUM Repository - Bug #3710] (Resolved) RHEL7postgresql11 postgis2.5 fails with /usr/pgsql-11/lib/postgis-2.5.so:undefined symbol: geod_polygon_init
From
Justin Pryzby
Date:
This appears to be more or less same as issue #3710. See earlier communiction, copied below. Just reinstalling postgis on a centos7 test server which previously ran postgres 11 beta. Installing : geos37-3.7.0-1.rhel7.1.x86_64 Installing : postgis24_11-2.4.6-3.rhel7.x86_64 Installing : postgis24_11-client-2.4.6-3.rhel7.x86_64 sentinel=# \i /usr/pgsql-11/share/contrib/postgis-2.4/postgis.sql BEGIN SET DO CREATE FUNCTION psql:/usr/pgsql-11/share/contrib/postgis-2.4/postgis.sql:95: ERROR: could not load library "/usr/pgsql-11/lib/postgis-2.4.so":/usr/pgsql-11/lib/postgis-2.4.so: undefined symbol: GEOSFrechetDistanceDensify [pryzbyj@template0 ~]$ ldd /usr/pgsql-11/lib/postgis-2.4.so libgeos_c.so.1 => /usr/geos36/lib64/libgeos_c.so.1 (0x00007f3e50e6e000) libgeos-3.6.2.so => /usr/geos36/lib64/libgeos-3.6.2.so (0x00007f3e4f12e000) Fixed with: rpm -e geos36-3.6.2-3.1.rhel7.x86_64 Should declare the RPM equivalent of debian's "Breaks" ?? On Wed, Dec 19, 2018 at 02:21:07PM -0600, Justin Pryzby wrote: > On Mon, Dec 10, 2018 at 11:33:52AM +0000, redmine@postgresql.org wrote: > > Issue #3710 has been updated by Devrim Gündüz. > > Status changed from In Testing to Resolved > > On Mon, Dec 10, 2018 at 09:06:43AM -0600, Justin Pryzby wrote: > > Does that work for upgrades from PG10 + postgis, which would probably have > > older geos installed ? > > I went to the effort to check: > > [pryzbyj@dev ~]$ /usr/pgsql-10/bin/initdb -D ./pgsql.tmp > [pryzbyj@dev ~]$ /usr/pgsql-10/bin/postmaster -D pgsql.tmp -c port=5678 -c unix_socket_directories=/tmp > [pryzbyj@dev ~]$ psql --host /tmp --port 5678 postgres -c 'CREATE EXTENSION postgis' > [pryzbyj@dev ~]$ time /usr/pgsql-11/bin/pg_upgrade -b /usr/pgsql-10/bin/ -B /usr/pgsql-11/bin/ -d ./pgsql.tmp -D pgsql.tmp11 > [pryzbyj@dev ~]$ /usr/pgsql-10/bin/pg_ctl -D pgsql.tmp stop > [pryzbyj@dev ~]$ time /usr/pgsql-11/bin/pg_upgrade -b /usr/pgsql-10/bin/ -B /usr/pgsql-11/bin/ -d ./pgsql.tmp -D pgsql.tmp11 > ... > > Checking for presence of required libraries fatal > > [pryzbyj@dev ~]$ cat loadable_libraries.txt > could not load library "$libdir/postgis-2.4": ERROR: incompatible library "/usr/pgsql-11/lib/postgis-2.4.so": versionmismatch > DETAIL: Server is version 11, library is version 10. > could not load library "$libdir/rtpostgis-2.4": ERROR: could not access file "$libdir/rtpostgis-2.4": No such file ordirectory > > I'd be interested to know if there's some reason why this would work on a fresh > centos7 install (or one without historic packages installed), but I think it > ought to work even on nonfresh installs, which are the ones where pg_upgrade is > more likely to be used. > > Justin
Re: [PostgreSQL YUM Repository - Bug #3710] (Resolved) RHEL7postgresql11 postgis2.5 fails with /usr/pgsql-11/lib/postgis-2.5.so:undefined symbol: geod_polygon_init
From
Christoph Berg
Date:
Re: Justin Pryzby 2019-01-07 <20190107215410.GA22493@telsasoft.com> > This appears to be more or less same as issue #3710. See earlier communiction, > copied below. > > Just reinstalling postgis on a centos7 test server which previously ran > postgres 11 beta. > > Installing : geos37-3.7.0-1.rhel7.1.x86_64 > Installing : postgis24_11-2.4.6-3.rhel7.x86_64 > Installing : postgis24_11-client-2.4.6-3.rhel7.x86_64 > > sentinel=# \i /usr/pgsql-11/share/contrib/postgis-2.4/postgis.sql > BEGIN > SET > DO > CREATE FUNCTION > psql:/usr/pgsql-11/share/contrib/postgis-2.4/postgis.sql:95: ERROR: could not load library "/usr/pgsql-11/lib/postgis-2.4.so":/usr/pgsql-11/lib/postgis-2.4.so: undefined symbol: GEOSFrechetDistanceDensify This has just popped up again on IRC, with postgis24_96-2.4.6-3.rhel7.x86_64 Why does postgis-2.4.so even "see" the geos37 package? > [pryzbyj@template0 ~]$ ldd /usr/pgsql-11/lib/postgis-2.4.so > libgeos_c.so.1 => /usr/geos36/lib64/libgeos_c.so.1 (0x00007f3e50e6e000) > libgeos-3.6.2.so => /usr/geos36/lib64/libgeos-3.6.2.so (0x00007f3e4f12e000) > > Fixed with: rpm -e geos36-3.6.2-3.1.rhel7.x86_64 > Should declare the RPM equivalent of debian's "Breaks" ?? Christoph
Re: [PostgreSQL YUM Repository - Bug #3710] (Resolved) RHEL7postgresql11 postgis2.5 fails with /usr/pgsql-11/lib/postgis-2.5.so:undefined symbol: geod_polygon_init
From
John Harvey
Date:
Hi Christoph (and others),
I believe the issue that remains could be pretty easily fixed when Devrim releases geos 3.7.0-2. That patch version contains an Obsoletes so that geos37 will obsolete geos36, which I think would solve the functionality problem. I did some testing locally with that change, and it seemed to work. Since geos37 only adds functionality on top of geos36 and has no breaking changes, it should be an okay solution to solve the "having 2 geos's on at the same time is a problem" issue.
Regards,
-John
-----------------------
On Thu, Feb 21, 2019 at 8:26 AM Christoph Berg <myon@debian.org> wrote:
Re: Justin Pryzby 2019-01-07 <20190107215410.GA22493@telsasoft.com>
> This appears to be more or less same as issue #3710. See earlier communiction,
> copied below.
>
> Just reinstalling postgis on a centos7 test server which previously ran
> postgres 11 beta.
>
> Installing : geos37-3.7.0-1.rhel7.1.x86_64
> Installing : postgis24_11-2.4.6-3.rhel7.x86_64
> Installing : postgis24_11-client-2.4.6-3.rhel7.x86_64
>
> sentinel=# \i /usr/pgsql-11/share/contrib/postgis-2.4/postgis.sql
> BEGIN
> SET
> DO
> CREATE FUNCTION
> psql:/usr/pgsql-11/share/contrib/postgis-2.4/postgis.sql:95: ERROR: could not load library "/usr/pgsql-11/lib/postgis-2.4.so": /usr/pgsql-11/lib/postgis-2.4.so: undefined symbol: GEOSFrechetDistanceDensify
This has just popped up again on IRC, with postgis24_96-2.4.6-3.rhel7.x86_64
Why does postgis-2.4.so even "see" the geos37 package?
> [pryzbyj@template0 ~]$ ldd /usr/pgsql-11/lib/postgis-2.4.so
> libgeos_c.so.1 => /usr/geos36/lib64/libgeos_c.so.1 (0x00007f3e50e6e000)
> libgeos-3.6.2.so => /usr/geos36/lib64/libgeos-3.6.2.so (0x00007f3e4f12e000)
>
> Fixed with: rpm -e geos36-3.6.2-3.1.rhel7.x86_64
> Should declare the RPM equivalent of debian's "Breaks" ??
Christoph
Re: [PostgreSQL YUM Repository - Bug #3710] (Resolved) RHEL7postgresql11 postgis2.5 fails with /usr/pgsql-11/lib/postgis-2.5.so:undefined symbol: geod_polygon_init
From
Justin Pryzby
Date:
On Thu, Feb 21, 2019 at 02:26:06PM +0100, Christoph Berg wrote: > Why does postgis-2.4.so even "see" the geos37 package? > > > [pryzbyj@template0 ~]$ ldd /usr/pgsql-11/lib/postgis-2.4.so > > libgeos_c.so.1 => /usr/geos36/lib64/libgeos_c.so.1 (0x00007f3e50e6e000) > > libgeos-3.6.2.so => /usr/geos36/lib64/libgeos-3.6.2.so (0x00007f3e4f12e000) > > > > Fixed with: rpm -e geos36-3.6.2-3.1.rhel7.x86_64 > > Should declare the RPM equivalent of debian's "Breaks" ?? Note that the problem was postgis24 was "seeing" geos 36 INSTEAD OF 37, not that it was seeing 37. I don't know about debian (from which I've been absent for a decade), but I think for centos it's because of this: [pryzbyj@template0 ~]$ rpm -ql geos37-3.7.0-1.rhel7.1.x86_64 /etc/ld.so.conf.d/geos37-pgdg-libs.conf ... [pryzbyj@template0 ~]$ cat /etc/ld.so.conf.d/geos37-pgdg-libs.conf /usr/geos37/lib64/ [pryzbyj@database ~]$ rpm -ql geos36 /etc/ld.so.conf.d/geos36-pgdg-libs.conf ... [pryzbyj@database ~]$ cat /etc/ld.so.conf.d/geos36-pgdg-libs.conf /usr/geos36/lib64/ Presumably, if both are installed it finds geos36-pgdg-libs.conf first, thus linker uses to geos36. I think to fully resolve this it's necessary to *prohibit* co-installation of new postgis with old geos. But note that's not adequately resolved by releasing a new geos36, since someone might run rpm/dpkg -i on a single package, without installing all the other updates from the repo. Justin
Re: [PostgreSQL YUM Repository - Bug #3710] (Resolved) RHEL7postgresql11 postgis2.5 fails with /usr/pgsql-11/lib/postgis-2.5.so:undefined symbol: geod_polygon_init
From
Christoph Berg
Date:
Re: Justin Pryzby 2019-02-21 <20190221163030.GY28750@telsasoft.com> > On Thu, Feb 21, 2019 at 02:26:06PM +0100, Christoph Berg wrote: > > Why does postgis-2.4.so even "see" the geos37 package? > > > > > [pryzbyj@template0 ~]$ ldd /usr/pgsql-11/lib/postgis-2.4.so > > > libgeos_c.so.1 => /usr/geos36/lib64/libgeos_c.so.1 (0x00007f3e50e6e000) > > > libgeos-3.6.2.so => /usr/geos36/lib64/libgeos-3.6.2.so (0x00007f3e4f12e000) Ah, I'm spotting this only now: The problem is that libgeos_c.so.1 doesn't have "3.6" in its SONAME, so a 3.7-linked postgis.so will try to load libgeos_c.so.1, find the 3.6 one, and explode. Or is libgeos_c.so.1 supposed to be independent from the geos version? Christoph