Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gKSnY-000885-Db for pgsql-pkg-yum@arkaria.postgresql.org; Wed, 07 Nov 2018 18:43:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gKSlP-0006kq-RD for pgsql-pkg-yum@arkaria.postgresql.org; Wed, 07 Nov 2018 18:41:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gKSlP-0006kg-GX for pgsql-pkg-yum@lists.postgresql.org; Wed, 07 Nov 2018 18:41:15 +0000 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gKSlL-0005bN-Ii for pgsql-pkg-yum@postgresql.org; Wed, 07 Nov 2018 18:41:15 +0000 Received: by mail-pl1-x641.google.com with SMTP id s5-v6so8232977plq.11 for ; Wed, 07 Nov 2018 10:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cleverelephant-ca.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5Tiz0u2v461LIFao0lge1ZEuwix7t3MnXsvCk1ByvqM=; b=QxfOQCCPEAxSzOag+RFiqu7nNB0oLgdpKq/FmAbxOj/UQbsIvllbuMguzKxs2v/TSw Kr5tXirBb2aNeB+ssj1BAI5kblvDwS6yHyWS1e7DJuqStkLK3oyo/7Zj1husN0O9y2/z Oy5iMq0QQo3LsbCiKs5dqVXTbv7/L0XvM8WhhdM5MYLsLX6cEXmQmWhSzhCe4YegNizW KGQE5N7RLZzy75a2X4NHL5FtF31regWa+HErb66cE6MQRsP4QNmEplCQbFZTuFebhQzG kj53IDCRr0CATgzPvlmzYeEhrWksGvQ4uODmGAo3B/r+GXjjZ5rqI/lV4/BiqQAAKJq9 lRbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5Tiz0u2v461LIFao0lge1ZEuwix7t3MnXsvCk1ByvqM=; b=ptIa2tPupmAuvQhFTr1C/n2/udI6Ujr+k6vgrLHnDU1rA3GV8wKT40ctoku5TNVgAl zVjEfHyRPuobRGmIUoEqhg88oP9pB4jB9+Y5sXHwUIZpwMFnO+GV2dxZ2wvkR1OpbgdR 4zItwLSYbRqafaHSZzKlzhj0IajXgzNieAGVUJpewwLBPoNNAOphrrtgosYxBrzLJ3Jx qvVTx2fPagchxZuH/Ywro1EdT8jsexmQm1fIGCNNrg0qYD1HSGA830hvu4dETo4Yn2Xy iqzgPxmwsZJdfEo3LnJ0QtPTekwmNGrXNEqEfq4k5cWK10BwNTgipaXkN3LxG5ftB/NH k3rw== X-Gm-Message-State: AGRZ1gIo4AbEJKWUlsDkKSN4j2z288JiUVK0uY8R1p+4Ci//Jiyuj+aU zPmOdVWFVC0Bb4uouyLOTDl5Mw== X-Google-Smtp-Source: AJdET5csI+HbfsgbYYD07LGHH2e/ajZjqgr4GA2uH3dDvJhs40T5vbjgokZmbCnS7DSo8wIjJEiFHQ== X-Received: by 2002:a17:902:9a44:: with SMTP id x4-v6mr1306658plv.121.1541616068017; Wed, 07 Nov 2018 10:41:08 -0800 (PST) Received: from [10.0.101.114] (S010624a43c3c2590.gv.shawcable.net. [184.66.241.40]) by smtp.gmail.com with ESMTPSA id r137-v6sm1813593pfc.105.2018.11.07.10.41.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 10:41:06 -0800 (PST) From: Paul Ramsey Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_764A72D0-2EEA-4D2B-9CEB-939D1081B509" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: error creating postgis25 extension on postgis 11 Date: Wed, 7 Nov 2018 10:41:05 -0800 In-Reply-To: Cc: pgsql-pkg-yum@postgresql.org To: Richard Huesken References: X-Mailer: Apple Mail (2.3445.9.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --Apple-Mail=_764A72D0-2EEA-4D2B-9CEB-939D1081B509 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The problem is definitely due to the presence of two proj libraries at = once, and postgis picking up on the =E2=80=9Cwrong=E2=80=9D one first. = You can force-remove the 4.8 one and run ldconfig and probably things = work fine then.=20 Not sure how it=E2=80=99s happening, the spec file for postgis25 seems = to make sense WRT what it=E2=80=99s declaring for dependencies: = https://git.postgresql.org/gitweb/?p=3Dpgrpms.git;a=3Dblob;f=3Drpm/redhat/= master/postgis25/master/postgis25.spec;h=3Da5bea2381fe78ef8b922ebd135ddf7b= d683bffc0;hb=3Drefs/heads/master = I=E2=80=99m not sure why the =E2=80=9Cproj49=E2=80=9D package doesn=E2=80=99= t supercede and remove the =E2=80=9Cproj=E2=80=9D package. P > On Nov 4, 2018, at 7:56 AM, Richard Huesken = wrote: >=20 > Hi, >=20 > On my Oracle Linux 7 box I had troubles vreating a postgis extension: >=20 > create extension postgis >=20 >=20 > The error is: > SQL Error [XX000]: ERROR: could not load library = "/usr/pgsql-11/lib/postgis-2.5.so ": = /usr/pgsql-11/lib/postgis-2.5.so : undefined = symbol: geod_polygon_init > ERROR: could not load library "/usr/pgsql-11/lib/postgis-2.5.so = ": /usr/pgsql-11/lib/postgis-2.5.so = : undefined symbol: geod_polygon_init >=20 > This might be a packaging error in the postgis25_11 package for Oracle = Linux 7. > I tried to create a ticket for this issue, however I'm not sure if = this worked out correctly. >=20 > I'm sending this mail just to be sure...=20 >=20 >=20 > [root@ol-pg11 lib64]# uname -a > Linux ol-pg11.rihu-ho 4.1.12-124.20.7.el7uek.x86_64 #2 SMP Wed Oct 24 = 14:15:06 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux >=20 >=20 > [root@ol-pg11 ~]# yum list installed | grep proj > proj.x86_64 4.8.0-4.el7 = @epel > proj49.x86_64 4.9.3-3.rhel7.1 = @pgdg11 >=20 > Indeed there are 2 dependencies in my postgis25_11 package: >=20 > [root@ol-pg11 ~]# yum deplist postgis25_11 > Loaded plugins: langpacks, ulninfo > package: postgis25_11.x86_64 2.5.0-1.rhel7.1 > ... > dependency: libproj.so.0()(64bit) > provider: proj.x86_64 4.8.0-4.el7 > dependency: libproj.so.12()(64bit) > provider: proj49.x86_64 4.9.3-3.rhel7.1 > ... >=20 > postgis-2.5.so seems to be using the one in = the /lib64 directory: >=20 > [root@ol-pg11 lib]# ldd postgis-2.5.so > ... > libproj.so.0 =3D> /lib64/libproj.so.0 (0x00007f6792485000) > ... >=20 > The proj4.8 version is located in /lib64 >=20 > [root@ol-pg11 lib]# cd /lib64/ > [root@ol-pg11 lib64]# ls -l libproj.so* > lrwxrwxrwx. 1 root root 16 Oct 29 13:36 libproj.so.0 -> = libproj.so.0.7.0 > -rwxr-xr-x. 1 root root 338168 Jan 24 2014 libproj.so.0.7.0 >=20 > Whereas the proj4.9 version is located in /usr/proj49/lib >=20 > [root@ol-pg11 lib64]# find / -name libproj.so.12 > /usr/proj49/lib/libproj.so.12 >=20 > The postgis25_11 package should only reference the the proj4.9 = version. > Once I fix this manually by changing the symlink I am able to create = the postgis extension. >=20 > The permanent option is to fix the package, hope you agree on this, >=20 > Kind regards, > Richard. >=20 --Apple-Mail=_764A72D0-2EEA-4D2B-9CEB-939D1081B509 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = problem is definitely due to the presence of two proj libraries at once, = and postgis picking up on the =E2=80=9Cwrong=E2=80=9D one first. You can = force-remove the 4.8 one and run ldconfig and probably things work fine = then. 
Not sure how it=E2=80=99s happening, the spec = file for postgis25 seems to make sense WRT what it=E2=80=99s declaring = for dependencies:

https://git.postgresql.org/gitweb/?p=3Dpgrpms.git;a=3Dblob;f=3D= rpm/redhat/master/postgis25/master/postgis25.spec;h=3Da5bea2381fe78ef8b922= ebd135ddf7bd683bffc0;hb=3Drefs/heads/master

I=E2=80=99m not sure why the = =E2=80=9Cproj49=E2=80=9D package doesn=E2=80=99t supercede and remove = the =E2=80=9Cproj=E2=80=9D package.

P

On Nov = 4, 2018, at 7:56 AM, Richard Huesken <richard.huesken@gmail.com> wrote:

Hi,

On my Oracle Linux 7 box = I had troubles vreating a postgis extension:

create extension postgis


The error is:
SQL Error [XX000]: ERROR: = could not load library "/usr/pgsql-11/lib/postgis-2.5.so": = /usr/pgsql-11/lib/postgis-2.5.so: undefined symbol: = geod_polygon_init
  ERROR: could not load = library "/usr/pgsql-11/lib/postgis-2.5.so": /usr/pgsql-11/lib/postgis-2.5.so: undefined = symbol: geod_polygon_init

This might be a packaging error in the postgis25_11 package = for Oracle Linux 7.
I tried to create a ticket for = this issue, however I'm not sure if this worked out correctly.

I'm sending this mail = just to be sure... 


[root@ol-pg11 lib64]# = uname -a
Linux ol-pg11.rihu-ho = 4.1.12-124.20.7.el7uek.x86_64 #2 SMP Wed Oct 24 14:15:06 PDT 2018 x86_64 = x86_64 x86_64 GNU/Linux


[root@ol-pg11 ~]# yum = list installed | grep proj
proj.x86_64    =                     =     4.8.0-4.el7            =      @epel
proj49.x86_64  =                     =     4.9.3-3.rhel7.1            =  @pgdg11

Indeed there are 2 dependencies in my postgis25_11 = package:

[root@ol-pg11 ~]# yum deplist postgis25_11
Loaded plugins: langpacks, ulninfo
package: postgis25_11.x86_64 2.5.0-1.rhel7.1
...
  dependency: = libproj.so.0()(64bit)
   provider: = proj.x86_64 4.8.0-4.el7
  dependency: = libproj.so.12()(64bit)
   provider: = proj49.x86_64 4.9.3-3.rhel7.1
...

postgis-2.5.so seems to = be using the one in the /lib64 directory:

[root@ol-pg11 lib]# ldd postgis-2.5.so
...
        = libproj.so.0 =3D> /lib64/libproj.so.0 (0x00007f6792485000)
...

The proj4.8 version is located in /lib64

[root@ol-pg11 lib]# cd = /lib64/
[root@ol-pg11 lib64]# ls -l = libproj.so*
lrwxrwxrwx. 1 root root    =  16 Oct 29 13:36 libproj.so.0 -> libproj.so.0.7.0
-rwxr-xr-x. 1 root root 338168 Jan 24  2014 = libproj.so.0.7.0

Whereas the proj4.9 version is located in = /usr/proj49/lib

[root@ol-pg11 lib64]# find / -name libproj.so.12
/usr/proj49/lib/libproj.so.12

The postgis25_11 package should only = reference the the proj4.9 version.
Once I fix this = manually by changing the symlink I am able to create the postgis = extension.

The = permanent option is to fix the package, hope you agree on = this,

Kind = regards,
Richard.


= --Apple-Mail=_764A72D0-2EEA-4D2B-9CEB-939D1081B509--