Postgis subbornly ignores specific instructions to link libraries like a child with severe ADHD

[thx1138]

Version 2.1.0SVN (today) OS Ubuntu 12.10 Server AMD64 GEOS: 3.4.0DEV GDAL: 1.10.0

I have spent the past few days of my life trying to figure out how to get postgis to function properly with a non-standard directory installation of postgres 9.3, but have been unable to resolve the following obnoxious errors:

ERROR: could not load library "/pginstall/postgresql93/lib/postgis-2.1.so": libgeos_c.so.1: cannot open shared object file: No such file or directory

Error

ERROR: could not load library "/pginstall/postgresql93/lib/postgis-2.1.so": libgeos_c.so.1: cannot open shared object file: No such file or directory SQL state: 58P01

I installed geos,gdal and postgres into self-contained directories in order to be able to update components without needing to manually find individual files and remove them.

Thus my libraries would be located in the following installation directories:

/pginstall/postgresql93/lib /pginstall/gdal110/lib /pginstall/geos34/lib All other dependencies are installed using standard apt packages and I am using the standard build-essential package.

I tried setting various environment variables

export LD_LIBRARY_PATH=/pginstall/geos34/lib:/pginstall/gdal110/lib

export LDFLAGS="-Wl,-rpath,/pginstall/geos34/lib/,-rpath,/pginstall/postgresql93/lib,-rpath,/pginstall/gdal110/lib"

export LDFLAGS="-Wl,L,/pginstall/geos34/lib,L,/pginstall/postgresql93/lib,L,/pginstall/gdal110/lib"

export LDFLAGS="-L/pginstall/geos34/lib -Wl,-rpath,/pginstall/geos34/lib"

export LDFLAGS="-Wl,-rpath,/pginstall/geos34/lib/,-rpath,/pginstall/gdal110/lib"

But they all failed to work with the configuration below

./configure \

—prefix=/pginstall/postgresql93 \

—with-pgconfig=/pginstall/postgresql93/bin/pg_config \

—with-geosconfig=/pginstall/geos34/bin/geos-config \

—with-gdalconfig=/pginstall/gdal110/bin/gdal-config \

—with-topology \

—with-raster

I did manage to get this working by adding the LD_LIBRARY_PATH variable to my upstart configuration for postgres —but this is a crude hack and is clearly not suitable for any kind of pre-production or production environment. I don't want to go the ldconfig route either, as that requires root access which is unnecessary.

I can verify that this issue is that the postgis configure process is ignoring my direct commands to add the paths to the binaries, by running the following command:

chrpath -l /pginstall/postgis/postgis-2.1.0SVN/postgis/postgis-2.1.so which yields

RPATH=/pginstall/postgresql93/lib The LDFLAG commands work when compiling GDAL with GEOS and Postgres, so I believe this is a postgis specific issue.

One would assume that postgis should know where the libraries are, given that I set them explicitly in the configure step and after concurrently setting LD_LIBRARY_PATH and LD_FLAGS. This is pretty depressing. What more should one need to specify?

Is there a workaround?

[robe]

thx1138 as one who builds with non-standard configs, of course very different from yours,and probably with fewer problems than you have with it, I can't help but butt my nose where it shouldn't be.

Where is your liblwgeom..so installed. It's my understanding that on other people's systems except mine it gets installed as a shared dll and often winds up in system somewhere. see thread ​http://lists.osgeo.org/pipermail/postgis-devel/2013-May/023477.html

I still blame any issues I have with this switching to a separate shared file.

[thx1138]

Replying to robe:

thx1138 as one who builds with non-standard configs, of course very different from yours,and probably with fewer problems than you have with it, I can't help but butt my nose where it shouldn't be.

Where is your liblwgeom..so installed. It's my understanding that on other people's systems except mine it gets installed as a shared dll and often winds up in system somewhere. see thread ​http://lists.osgeo.org/pipermail/postgis-devel/2013-May/023477.html

I still blame any issues I have with this switching to a separate shared file.

Relevant paths:

/pginstall/postgresql93/lib/liblwgeom-2.1.0SVN.so /pginstall/postgresql93/lib/liblwgeom.so

Everything is installed in the correct location, but the paths for gdal and geos are just not being embedded in the created binaries. Basically as far as I can tell, some part of the installation is destroying my rpath settings and I have no clue as to how to stop it from doing this.

[strk]

First of all this has nothing to do with liblwgeom, but only with libgeos not being found at runtime. I believe the correct way to deal with this is by setting LD_LIBRARY_PATH in the server environment, but I understand you'd prefer to embed an rpath into the postgis.so object.

I've never felt any need for this so don't really know how to do it, but I guess your LDFLAGS should be respected. Can you check if the resulting link command still have the -rpath in ? Either in the output of "make" under postgis/ dir or within the Makefile itself.

Also, I guess the _same_ issue you'll have with _any_ precedent PostGIS version, can you confirm ?

[strk]

4 months with no feedback from original author, expiring.

[rajanski]

Havin the same problemon Centos

ldd outputs show everything is fine,still executing postgis.sql leads tothe same message as initially mentioned

[rajanski]

Also see ​http://stackoverflow.com/questions/17915928/error-when-installing-postgis-extension-to-postgresql-database , last post

[strk]

Another 3 years are gone, I'm closing again. Feel free to reopen if you really think rpath should be used and still cannot add them. NOTE that pramsey fixed an override of CFLAGS in r16019 so maybe there's room for fixing another override of LDFLAGS for this case …