3

Im having problem installing postgis to an existing database. but getting error like this:

ERROR:  could not load library "/usr/local/pgsql/lib/postgis-2.0.so": libgeos_c.so.1: cannot open shared object file: No such file or directory

the postgis-2.0.so is in /usr/local/pgsql/lib/postgis-2.0.so no problem. the libgeos_c.so.1 is installed in /usr/local/lib.

So, what is the problem here?

Any help would be appreciated.

Thanks.

BTW, I installed all these followed by this tutorial:

http://www.codingsteps.com/installing-and-configuring-postgresql-in-amazon-linux-ami/

update

$ ldd /usr/local/lib/libgeos_c.so.1
linux-vdso.so.1 =>  (0x00007fff6f55b000)
libgeos-3.3.7.so => /usr/local/lib/libgeos-3.3.7.so (0x00007f53700d9000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f536fdd0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f536fb4c000)
libc.so.6 => /lib64/libc.so.6 (0x00007f536f7c0000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f536f5ab000)
/lib64/ld-linux-x86-64.so.2 (0x00007f537068d000)
Improve this question

7 Answers 7

Reset to default
5

It's way easier to just use a sensible Linux distro like Ubuntu, Debian, Fedora, RHEL, etc. You can then just use http://apt.postgresql.org/ or http://yum.postgresql.org/ as appropriate and get all this stuff pre-built and easy to install. Amazon's PostgreSQL packaging is unsafe bordering on incompetent and should be avoided.

I suspect the immediate problem is /usr/local/lib not being on LD_LIBRARY_PATH and/or in /etc/ld.so.conf, so when PostgreSQL dlopen(...)'s postgis-2.0.so it tries to resolve libgeos_c.so.1 and fails to find it.

Another possibility would be if /usr/local/lib/libgeos_c.so.1 is a symbolic link to a file that does not exist.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

hey Craig, thanks for your reply. I've just tried export LD_LIBRARY_PATH=/usr/local/lib but it not seem to be working. Any idea?
@Still.Wang Well, just exporting the env var into your shell won't make any difference, since it'd only do anything if you set the environment of the postgresql server process. You'd need to modify the init script for postgresql or add it to /etc/ld.so.conf so it affects every program globally.
just checked that file and the content was include ld.so.conf.d/*.conf /usr/local/lib
sorry, im really not a linux guy. :(
OK, so your next step would generally be to run ldd /usr/local/lib/libgeos_c.so.1 . See if there are any errors or missing dependencies. Seriously, though, if you're "not really a Linux guy" you should just throw this virtual machine away and replace it with a nice sensible Ubuntu or Fedora VM where there are official PostgreSQL packages including PostGIS, etc. You're doing it the hard way.
|
5

If you installed the postgis by source, maybe you forgot to run sudo ldconfig. Running this worked for me!

Thank you Yunwei.W, i saw this in the wiki you shared!

Improve this answer

1 Comment

this saved the day for me
2

I seem to have faced similar problem accidentally. On Cent OS 6 I installed binary PostgreSQL 9.3 from PostgreSQL YUM repository. Compiled GDAL library version 1.11.0 from official stable tar. Then compiled PostGIS 2.1.4dev from original PostGIS repository. Unit tests showed, that libgdal was not loaded because it was not found. Error message looked similar to one in the original question. @Craig gave idea of using strace. The point is in attaching strace specifically to the process that was created just after the connection of client to DBMS. After you attach strace to DBMS, make client ask server to CREATE EXTENSION postgis on current database and see the output of strace. In my case it gave this:

open("/lib64/tls/x86_64/libgdal.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/lib64/tls/x86_64", 0x7fffefb20290) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libgdal.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
open("/lib64/x86_64/libgdal.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/lib64/x86_64", 0x7fffefb20290)   = -1 ENOENT (No such file or directory)
open("/lib64/libgdal.so.1", O_RDONLY)   = -1 ENOENT (No such file or directory)
stat("/lib64", {st_mode=S_IFDIR|0555, st_size=12288, ...}) = 0
open("/usr/lib64/tls/x86_64/libgdal.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls/x86_64", 0x7fffefb20290) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libgdal.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
open("/usr/lib64/x86_64/libgdal.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/x86_64", 0x7fffefb20290) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libgdal.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib64", {st_mode=S_IFDIR|0555, st_size=12288, ...}) = 0

It shows which specific paths DBMS tries to find library in. In my situation library lies in /usr/local/lib/libgdal.so.1.18.0 with symbolic links for broader version use in same directory. My solution was to put symbolic links to these files into /usr/lib64 directory.

Improve this answer

1 Comment

Can you tell me as to what you did to copy over all the symlinks to the directory also you just seem to be having all the synlinks in /lib64 in my case its in different directories what do you propose for that. I am kinda stuck at this process.
1

It's been a while since I've solved this problem, and almost forgot this question i asked before. I found still getting upvote from guys might having this issue.

So basically, I found this issue might be happening because of the postgis plugin which i installed by sudo apt-get install postgis wasn't properly installed into the position which PostgreSQl database preferred. Im really not a linux guy to make sure of this. But seems every time I try installing postgis this way, this error will just show up.

So the cure for this issue is, download, build and install the postgis from the source code.

I followed this wiki. hope its helpful to someone.

Improve this answer

Comments

1

/etc/ld.so.conf.d/ should contain paths for postgresql libs dir and geos libs.

Example for postgresql 9.6.6 on Amazon linux:

-create postgresql-pgdg-libs.conf with "/usr/lib64/pgsql96/" path
-create libgeos.conf with "/usr/local/lib/" path 
-check the geos library present in 
 ldconfig -v | grep geos
- if yes compile the extension
sudo -u postgres -- psql -c "CREATE EXTENSION postgis;"
Improve this answer

Comments

0

This command works for me

sudo ln -s /usr/lib/x86_64-linux-gnu/libgeos_c.so.1 /usr/lib/

which basically symlinks to the location django wants it to be. By default, the libgeos_c.so.1 is installed in the /usr/lib/x86_64-linux-gnu folder

Improve this answer

Comments

0

if it helps anyone in the future, I had a similar problem (with postgis 3.0.1 now), and it turned out the root of the problem was that on AWS Linux 2, I had to manually install the pgxs part of postgres (to manage Extensions), and during that installation part of the ./configure command hard-coded a path for the extension libraries to /usr/lib64/perl5/CORE/ (where libperl.so lives). Here was the configure command:

(see the very last parameters)

/usr/lib64/pgsql/pgxs/src/Makefile.global:configure_args =  '--build=x86_64-koji-linux-gnu' '--host=x86_64-koji-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-rpath' '--with-perl' '--with-tcl' '--with-tclconfig=/usr/lib64' '--with-ldap' '--with-openssl' '--with-pam' '--with-gssapi' '--with-ossp-uuid' '--with-libxml' '--with-libxslt' '--enable-nls' '--enable-dtrace' '--with-selinux' '--with-system-tzdata=/usr/share/zoneinfo' '--datadir=/usr/share/pgsql' '--with-systemd' '--with-icu' '--with-python' 'build_alias=x86_64-koji-linux-gnu' 'host_alias=x86_64-koji-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-rpath=/usr/lib64/perl5/CORE/ -L/usr/lib64/perl5/CORE/' 'LDFLAGS=-Wl,-z,relro ' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

/usr/lib64/pgsql/pgxs/src/Makefile.global:CFLAGS = -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-rpath=/usr/lib64/perl5/CORE/ -L/usr/lib64/perl5/CORE/

Anyway, I eventually figured out through @progalgo 's mention of strace that the libraries that postgis was trying to use (when creating the extension) were housed in /usr/local/lib but no amount of configuring the LD_LIBRARY_PATH env variable would make it look there. So I moved the file from the perl folder over to /usr/local/lib, removed that /CORE directory, and symlinked "CORE" over to /usr/local/lib itself. A bit hack-y, but it worked.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.