Обсуждение: postgis/gdal - undefined symbol: proj_crs_has_point_motion_operation

Hello,

I got an error while creating or using postgis_raster. I seams a packaging or dependency problem:

create extension postgis_raster cascade;
....
FEHLER:  konnte Bibliothek >/usr/pgsql-15/lib/postgis_raster-3.so< nicht laden: /usr/gdal38/lib/libgdal.so.34:
undefinedsymbol: proj_crs_has_point_motion_operation 

I can reproduce this error on RHEL8 systems e.g.:
- PostgreSQL 13 + PostGIS 3.1 (3.1.11-3PGDG.rhel8)
- PostgreSQL 16 + PostGIS 3.4 (3.4.2-3PGDG.rhel8)

The installed gdal version of affected servers is 3.8.5-3PGDG.rhel8 .

Regards,

Christopher Lorenz

Hi,

On Mon, 2024-04-29 at 14:39 +0000, Lorenz, Christopher wrote:
> I got an error while creating or using postgis_raster. I seams a
> packaging or dependency problem:
>
> create extension postgis_raster cascade;
> ....
> FEHLER:  konnte Bibliothek >/usr/pgsql-15/lib/postgis_raster-3.so<
> nicht laden: /usr/gdal38/lib/libgdal.so.34: undefined symbol:
> proj_crs_has_point_motion_operation
>
> I can reproduce this error on RHEL8 systems e.g.:
> - PostgreSQL 13 + PostGIS 3.1 (3.1.11-3PGDG.rhel8)
> - PostgreSQL 16 + PostGIS 3.4 (3.4.2-3PGDG.rhel8)
>
> The installed gdal version of affected servers is 3.8.5-3PGDG.rhel8 .

What is the output of:

rpm -qa | grep proj

Regards,

--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR

Hi Devrim,

Thanks a lot for the question about the proj package. 

The result was:
$ rpm -qa | grep proj
proj94-9.4.0-1PGDG.rhel8.x86_64
proj82-8.2.1-3.rhel8.x86_64
proj92-9.2.1-1PGDG.rhel8.x86_64

The solution for me was to remove the old proj82 and proj92 rpms, gdal has used the proj92 library before. 

Now it works (PostGIS_full_version()):

POSTGIS="3.1.11 ca03d62" [EXTENSION] PGSQL="130" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0" GDAL="GDAL 3.8.5, released
2024/04/02"LIBXML="2.9.7" LIBJSON="0.13.1" LIBPROTOBUF="1.3.0" WAGYU="0.5.0 (Internal)" TOPOLO
 
GY RASTER

The automatic update on my server doesn't removes the old proj92 package. Is it possible and practical to define
conflictswith different proj versions in specs to avoid problems like these? 
 

Regards,

Christopher, Lorenz

-----Ursprüngliche Nachricht-----
Von: Devrim Gündüz <devrim@gunduz.org> 
Gesendet: Dienstag, 30. April 2024 11:43
An: Lorenz, Christopher <Christopher.Lorenz@ZIT-BB.Brandenburg.de>; pgsql-pkg-yum@postgresql.org
Betreff: Re: postgis/gdal - undefined symbol: proj_crs_has_point_motion_operation


Hi,

What is the output of:

rpm -qa | grep proj

Hi,

On Tue, 2024-04-30 at 13:16 +0000, Lorenz, Christopher wrote:
> The result was:
> $ rpm -qa | grep proj
> proj94-9.4.0-1PGDG.rhel8.x86_64
> proj82-8.2.1-3.rhel8.x86_64
> proj92-9.2.1-1PGDG.rhel8.x86_64
>
> The solution for me was to remove the old proj82 and proj92 rpms, gdal
> has used the proj92 library before.
>
> Now it works (PostGIS_full_version()):

<snip>

Great!

> The automatic update on my server doesn't removes the old proj92
> package. Is it possible and practical to define conflicts with
> different proj versions in specs to avoid problems like these?

I am not sure this is 100% safe. What happens when there is a PostGIS
version that cannot be compiled against newer Proj and someone wants to
install multiple PostGIS versions?

I'm not saying that the current situation is ok, just saying that I'm
not satisfies with the solutions that I thought so far.

Regards,
--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR

Re: Devrim Gündüz
> > proj94-9.4.0-1PGDG.rhel8.x86_64
> > proj82-8.2.1-3.rhel8.x86_64
> > proj92-9.2.1-1PGDG.rhel8.x86_64
> 
> > The automatic update on my server doesn't removes the old proj92
> > package. Is it possible and practical to define conflicts with
> > different proj versions in specs to avoid problems like these? 
> 
> I am not sure this is 100% safe. What happens when there is a PostGIS
> version that cannot be compiled against newer Proj and someone wants to
> install multiple PostGIS versions?

The packages are renamed for the new SONAMEs exactly for being able to
keep them around (there might be other software still using the older
versions, perhaps locally compiled things). Forcing them to be removed
would defeat that purpose.

Christoph