Re: GEOS 3.8.0
| От | Laurenz Albe |
|---|---|
| Тема | Re: GEOS 3.8.0 |
| Дата | |
| Msg-id | 868e611132b1516858dfd402b46eb33f98e62fe0.camel@cybertec.at обсуждение исходный текст |
| Ответ на | GEOS 3.8.0 (Paul Ramsey <pramsey@cleverelephant.ca>) |
| Ответы |
Re: GEOS 3.8.0
|
| Список | pgsql-pkg-yum |
On Thu, 2019-10-10 at 11:48 -0700, Paul Ramsey wrote: > FYI, fresh meat for the pipeline: > > https://lists.osgeo.org/pipermail/geos-devel/2019-October/009342.html I think something went wrong with packaging there, causing problems for people who upgrade their PostGIS installation. Here is an account of the problem I had at a customer: https://stackoverflow.com/a/61494358/6464308 Essentially, it should be impossible to have both geos37 and geos38 installed, because they both ship the library "libgeos_c" with the same library major version, even though the libraries are binary incompatible. "libgdal.so.26" from "gdal30-libs" is linked with this library from GEOS 3.8, but if GEOS 3.7 is also installed and happens to be first on the shared library path, it pulls the wrong one and fails with /usr/gdal30/lib/libgdal.so.26: undefined symbol: GEOSMakeValid_r Now it is easy to fix the problem by removing "geos37", but I think that the packages should avoid the problem. I leave the best solution to your discretion, but these are my ideas: - Add dependencies that forbid both packages to be installed at the same time. - Make sure that the GEOS 3.8 lib directory is always first on the shared library search path. Yours, Laurenz Albe
В списке pgsql-pkg-yum по дате отправления: