[postgis-users] Broken installs for PostGIS for Ubuntu 20.04LTS / Focal?

[Marco Boeringa]

Hi all,

Is there someone who can confirm they have been able to install PostGIS
3.0.1 via the official APT repository?:

https://wiki.postgresql.org/wiki/Apt

After using the Synaptics Package Manager to install the three packages
involved
("postgresql-12-postgis-3"/"postgresql-12-postgis-3-dbgsym"/"postgresql-12-postgis-3-scripts"),
and subsequently trying to create the PostGIS extension in pgAdmin4, I
get the following error:

ERROR: could not load library "/usr/lib/postgresql/12/lib/postgis-3.so":
/usr/lib/postgresql/12/lib/postgis-3.so: undefined symbol: GEOSMakeValid

I have been trying different things to fix this for past two days
including re-install, but to no avail. I have also attempted to include
the UbuntuGIS repository as a potential alternative resource of PostGIS
packages, but discovered the UbuntuGIS repository is lagging behind and
doesn't yet have packages for 20.04LTS.

Marco

_______________________________________________
postgis-users mailing list
postgi...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users

[Tom van Tilburg]

Same problem with qgis

[Marco Boeringa]

Thanks for the response Tom, but could you be a bit more specific?

What do you mean with "Same problem with qgis"? Do you mean you've also encountered a "undefined symbol: GEOSMakeValid" error related to the "postgis-3.so" library when trying to use some tool in QGIS?

I have installed PostgreSQL 12 and PostGIS 3.0.1 via Synaptic on Ubuntu 20.04 (Focal) and use CREATE EXTENSION (via pgAdmin4), when I encounter the error.

Marco

Op 13-5-2020 om 14:40 schreef Tom van Tilburg:

[Marco Boeringa]

Thanks Tom,

I have seen a similar error related to the "libgdal26" library, but that was after other trials to get something running on Ubuntu 20.04 Focal, where I successfully installed PostGIS 2.5.4, but then encountered issues when my code called the "postgis_full_version()" function and errored out with the error message below related to the "libgdal.so.26" library. However, as said, this was with PostGIS 2.5.4, not with the PostGIS 3.0.1 I actually want to install at this moment and that gave the other error related to the "postgis-3.so" library.

SQL Error [XX000]: ERROR: could not load library "/usr/lib/postgresql/11/lib/rtpostgis-2.5.so": /usr/lib/libgdal.so.26: undefined symbol: GEOSMakeValid_r
  Where: SQL statement "SELECT public.postgis_gdal_version()"
PL/pgSQL function postgis_full_version() line 34 at SQL statement

Marco

Sorry for the short answer, am on the way currently. Will try to do a decent report tonight.

Error is roughly the same but comes from libgdal26 in my case when doing apt install qgis after an upgrade to 20.04.

best, Tom

[Tom van Tilburg]

I just had the time to try a postgis install but reached to a different result of missing libCGAL.

Here's my setting:

Yesterday upgraded to Focal

- Added apt repo for postgres.

- Installed postgres-12 and postgis

- Tried to do 'CREATE EXTENSION postgis':

ERROR:  could not load library "/usr/lib/postgresql/12/lib/postgis-3.so": libCGAL_Core.so.13: cannot open shared object file: No such file or directory

I tried to manually install libcgal but this doesn't appear to be available for focal yet.

See: https://packages.ubuntu.com/search?keywords=cgal

The sfcgal library used by postgis is available though:

% sudo dpkg --list |grep cgal
ii  libcgal-dev:amd64                          5.0.2-3                               amd64        C++ library for computational geometry (development files)
ii  libsfcgal1                                 1.3.7-4ubuntu3                        amd64        Library for ISO 19107:2013 and OGC SFA 1.2 for 3D operations

Your email has a curious parallel to my installation attempt of qgis though which ended at:

Setting up qgis-providers (1:3.12.2+32focal) ...
/usr/lib/qgis/crssync: symbol lookup error: /usr/lib/libgdal.so.26: undefined symbol:
 GEOSMakeValid_r

Leaving me with an invalid setup of dpkg (only clears after uninstalling qgis-providers).

All in all, it seems the packages are in an incomplete state currently.

Tom

[Tom van Tilburg]

I think I solved it.

The issue lies with gdal, not postgis (test by running `gdalinfo`), and it turns out there was an old install of libgeos (3.7) in my /us/local/lib. After simply removing all related files in /usr/local/lib gdal (and postgis and qgis) stopped complaining (I had to remove old installs of geos, proj and sfcgal for that).

This issue put me on the right track:

https://github.com/OSGeo/gdal/issues/2214

T.

On Wed, May 13, 2020 at 3:15 PM Marco Boeringa <ma...@boeringa.demon.nl> wrote:

[Marco Boeringa]

Hi Tom,

Thanks for the tip, but what did you do to remove the old install? Did you rely on Apt or Synaptic to remove the old libgeos version, or did you manually clean up folders? I had two versions of libgeos as well (3.7 and 3.8) if I remember well (need to start up the VM again to check), and removed the older one through Synaptic just leaving the 3.8 version, but that wasn't enough to solve my particular issues.

Marco

Op 14-5-2020 om 10:32 schreef Tom van Tilburg:

[Tom van Tilburg]

Whatever lives in /usr/local/lib was my manual build so I had to delete that manually.

I did  `sudo rm /usr/local/lib/libgeos*` (same for proj and sfcgal)

On top of that I purged all old package configurations `sudo apt purge <packagename>` just to be sure but I don't think it is needed.

Best,

 Tom

[Marco Boeringa]

Tom,

Thanks for this info.

I now discovered that, despite removing the "libgeos-3.7.0" by using Synaptic, I also had a secondary version living in my "/usr/local/lib/" folder. Purging all "libgeos" prefixed files with the command you supplied, indeed made it now possible to use CREATE EXTENSION for PostGIS in pgAdmin4. So there was a conflict lurking there in the "/usr/local/lib/" folder. I actually have no idea how the libgeos files ended up there, or why they weren't removed by Synaptic if that used to be the official installation folder.

I don't know if this is the only issue though, and would need to start to test the current installation properly in order to make sure everything is truly OK now, but it is at least a significant step forward.

Marco

Op 14-5-2020 om 11:42 schreef Tom van Tilburg:

[Marco Boeringa]

Tom,

One more question:

After successfully installing the PostGIS 3.0.1 extension using CREATE EXTENSION in pgAdmin4 on PostgreSQL 12.3 on Ubuntu 20.04 Focal, I now ran into an issue where it appears the 'ST_Accum' function is missing in my PostGIS install. My code calls this, and it failed. I then had a look at the function list in pgAdmin, and indeed 'ST_Accum' is not listed. I do see loads of other PostGIS functions, just 'ST_Accum' seems missing (although I cannot garantuee there are a few more missing functions, but the list seems pretty comprehensive from a quick look, and the CREATE EXTENSION call went without a hitch).

Can you confirm you see 'ST_Accum' in your PostGIS 3.0.1 function list if you look in pgAdmin? The PostGIS Help does not mention some deprecation of this function:

https://postgis.net/docs/ST_Accum.html

Marco

Op 14-5-2020 om 11:42 schreef Tom van Tilburg:

Whatever lives in /usr/local/lib was my manual build so I had to delete that manually.

[Marco Boeringa]

Tom,

It now appears the PostGIS team indeed removed 'ST_Accum', but forgot to update the online PostGIS Help. I see two OSGEO tickets related to this:

https://trac.osgeo.org/postgis/ticket/4356

https://trac.osgeo.org/postgis/changeset/17397

Both mention replacing 'ST_Accum' with 'array_agg'.

Marco

Op 15-5-2020 om 10:38 schreef Marco Boeringa:

[Tom van Tilburg]

It's the first thing I ran into as well after upgrading .

But it hasn't been mentioned in the docs? Whoops... time for an issue...

Tom

[Darafei "Komяpa" Praliaskouski]

It is mentioned in changelog and removed from the docs. For some reason there is stray page from older release.

--

Darafei Praliaskouski

Support me: http://patreon.com/komzpa

[Regina Obe]

Yes stray doc.  Did you find this via google.  Looks like that page last got updated 4/17/2019.   It’s the nature of how we build the docs that the updates overwrite existing for a particular Minor version, but don’t delete.

So it existed early in the life cycle of 3.0 but was later removed

Anyway I’ve deleted ST_Length2D_Spheroid.html and ST_Point_Inside_Circle.html which also seemed to have the same issue

[Tom van Tilburg]

On Fri, May 15, 2020 at 1:33 PM Regina Obe <l...@pcorp.us> wrote:

Yes stray doc.  Did you find this via google. 

I usually 'guess' the page by just replacing the function name in the url. It's a very convenient way, apart from ST_Tessellate which is obviously spelled wrong in the docs.

 

Looks like that page last got updated 4/17/2019.   It’s the nature of how we build the docs that the updates overwrite existing for a particular Minor version, but don’t delete.

Makes sense, it is gone from the TOC so that is fine.

[Marco Boeringa]

Hi Regina,

Yes, I found this via Google. After the update, it now indeed errors out on a 404. ST_Collect also no longer mentions it, so that seems fine now.

I do slightly wonder by the way why ST_Accum wasn't simple re-implemented as a wrapper around 'array_agg'. While I appreciate breaking changes may be necessary and are to be expected for a major version update like 2.x to 3.x, in this particular case, where wrapping the function would have been an easy solution, could have avoided breaking existing code with minimal effort and maintenance overhead.

Anyway, the required code changes are luckily minimal as well, just replace 'ST_Accum()' with 'array_agg()' as per the OSGeo tickets I saw, so that is not a big deal. I have now implemented this in my own code.

Marc,

Op 15-5-2020 om 13:24 schreef Regina Obe:

[Regina Obe]

Several reasons

 

1)      Each function in itself is not that much, but compounded over many functions is a huge headache as if we change the newer version, we’d then have to remember to change the wrapper and in this case we’d have to keep track of what PostgreSQL is doing upstream since we have no control of array_agg.  Aggregates are especially annoying since we had a state function tied behind this.  So was really like 4 functions.

2)      array_agg has been in PostgreSQL for a long long time.  We assumed most users would be using that already instead of ST_Accum.  There really was no reason to use ST_Accum past PostGIS 1.5 for any version of PostgreSQL. Granted we should have put a note on the page – deprecated so people new we’d be taking it out.

3)      Wrappers  are slower.  In the case of ST_Accum(), I think it’s significantly slower

4)      People are already complaining about too many functions in PostGIS.  So keeping around old ones that we don’t want people using anyway just adds to the frustration of new users.

[Marco Boeringa]

Hi Regina,

Thanks for explaining the reasons behind this. Yes, in hindsight putting a note up about deprecation could have helped, although in my case the function was part of some code I found on the Net and adjusted a little, so I didn't really have a reason to lookup the 'ST_Accum' function in the Help up to now, so would still have run into this.

Anyway, it is fixed now, and the code runs fine after switching to 'array_agg'.

Marco

Op 15-5-2020 om 14:39 schreef Regina Obe: