Re: AW: postgis/gdal - undefined symbol: proj_crs_has_point_motion_operation

From: Devrim Gündüz <devrim(at)gunduz(dot)org>
To: "Lorenz, Christopher" <Christopher(dot)Lorenz(at)ZIT-BB(dot)Brandenburg(dot)de>, "pgsql-pkg-yum(at)postgresql(dot)org" <pgsql-pkg-yum(at)postgresql(dot)org>
Subject: Re: AW: postgis/gdal - undefined symbol: proj_crs_has_point_motion_operation
Date: 2024-05-01 09:07:27
Message-ID: 78fd412966536e4441e9bb3730d6441486d06c2e.camel@gunduz.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-pkg-yum

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

In response to

Responses

Browse pgsql-pkg-yum by date

  From Date Subject
Next Message Christoph Berg 2024-05-01 09:10:20 Re: AW: postgis/gdal - undefined symbol: proj_crs_has_point_motion_operation
Previous Message Lorenz, Christopher 2024-04-30 13:16:10 AW: postgis/gdal - undefined symbol: proj_crs_has_point_motion_operation