Subject: Re: [PostgreSQL YUM Repository - Bug #3710] (Resolved) RHEL7 postgresql11 postgis2.5 fails with /usr/pgsql-11/lib/postgis-2.5.so: undefined symbol: geod_polygon_init

From: Justin Pryzby <[email-masked]>
Date: Mon, 7 Jan 2019 15:54:10 -0600

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, [email-masked] 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": version mismatch
> 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 or directory
> 
> 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

---

From: Christoph Berg <[email-masked]>
Date: Thu, 21 Feb 2019 14:26:06 +0100

Re: Justin Pryzby 2019-01-07 <[email-masked]>
> 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: GEOSFrechetDistan…

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?

> Should declare the RPM equivalent of debian's "Breaks" ??

Christoph

---

From: John Harvey <[email-masked]>
Date: Thu, 21 Feb 2019 08:41:32 -0500

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

-----------------------
John Harvey
(843) 628-5421
Crunchy Data
Enterprise PostgreSQL
www.crunchydata.com

On Thu, Feb 21, 2019 at 8:26 AM Christoph Berg <[email-masked]> wrote:

> > 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
>

---

From: Justin Pryzby <[email-masked]>
Date: Thu, 21 Feb 2019 10:30:30 -0600

> > 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

---

From: Christoph Berg <[email-masked]>
Date: Thu, 21 Feb 2019 17:46:52 +0100

Re: Justin Pryzby 2019-02-21 <[email-masked]>
> > >         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