[postgis-devel] module linking issues

[Sandro Santilli]

On Wed, Jun 29, 2011 at 02:05:20PM +0000, Bryce L Nordgren wrote:
> On Tue, Jun 28, 2011 at 11:08 AM, Sandro Santilli <strk at keybit.net> wrote:
> 
> > On Tue, Jun 28, 2011 at 08:58:54AM -0600, Bryce L Nordgren wrote:
> > > On Mon, Jun 27, 2011 at 1:31 AM, Sandro Santilli <strk at keybit.net>
> > wrote:
> > >Wait a sec.
> > First of all, "make check" should be done _before_ "make install".
> >
> 
> My foggy memory seems to recall that make check tried to connect to a
> running database server, so I've been avoiding it (until I can get the
> server installed and running). I have yet to wrap my head around the postgis
> testing system, which seems to rely pretty heavily on SQL.

Yes, you need a running database server. The framework has an SQL heavy
component and an SQL-free component. I'm guessing your problem is with
the former, anyway.


> psql:rtpostgis-2.0/rtpostgis.sql:39: ERROR:  could not load library
> "/usr/lib/postgresql/rtpostgis-2.0.so": /home/bnordgr
> en/build/local/postgis-svn/src/trunk-build/postgis/postgis-2.0.so: cannot
> open shared object file: Permission denied

[...]

> liblwgeom is already statically linked to raster. I created a dependency
> from raster to postgis (which did not previously exist), and postgis exists
> only as a shared library. Mark's proposed solution was to move the needed
> code out of postgis and into liblwgeom, to exploit this existing static
> link. Doing so would create a dependency from liblwgeom to postgresql, which
> may not be compatible with the design goals of liblwgeom (waiting on an
> answer now).
> 
> I guess the fundamental issue is: how does one postgresql module depend on
> another? Postgis is dynamically linked because postgresql makes it be
> dynamically linked, right?

I hope Mark can answer this question, as since we went PGXS we kind of lost
some control over how we link things. The ERROR you printed above suggests
your added linking is performed trough an -rpath switch or something similar
encoding the builddir path into the rtpostgis-2.0.so file. You should either
not do that and let the system know where to find postgis-2.0.so OR you should
set that path to be the installation path, rather than the build path.

Note that using an -rpath makes it harder (if possible at all) to run the
regress testing using the just-built postgis library rather than the system
installed one...

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html