[postgis-devel] linkage against libpq.so (Sandro Santilli)

Sandro Santilli strk at keybit.net
Sun Oct 7 23:45:10 PDT 2012

On Sat, Oct 06, 2012 at 12:15:04PM -0700, Jeff Janes wrote:
> > Date: Fri, 5 Oct 2012 19:00:13 +0200
> > From: Sandro Santilli <strk at keybit.net>
> >
> > On Fri, Oct 05, 2012 at 09:48:42AM -0700, Jeff Janes wrote:
> >> So it is linking against the old version anyway.
> >
> > In that case it's a system configuration issue, not a PostGIS one.
> > I think it is a feature that the postgis binaries and scripts adapt
> > to whatever library the linker provides.
> By this, do you mean it is against project policy to use rpath?

I don't think there's an official policy, but I'm personally against
it as a default.

> > It's up to you to instruct
> > your linker. Try export LD_LIBRARY_PATH=/usr/local/pgsql/lib
> Yes, I can make it work that way, but that does make it hard to have
> multiple versions installed at the same time (for testing or
> development purposes, or just because some packages come with ancient
> dependencies).

I don't see how using LD_LIBRARY_PATH makes it harder.
If you need a script, wrap the LD_LIBRARY_PATH in a script.

> >> If I remove the rpm which is providing /usr/lib64/libpq.so.5 and then
> >> redo the config, make, and make install from scratch, it still doesn't
> >> link the appropriate libpq, now it links nothing at all:
> >>
> >> ldd /usr/local/pgsql/bin/pgsql2shp| fgrep pq
> >>         libpq.so.5 => not found
> >
> > Did you ldconfig after the removal (I'm hoping in an rpm bug).
> I hadn't.  If I do a pure "ldconfig", it still doesn't work but if I
> do a "ldconfig /usr/local/pgsql/lib" then it does work.  But I think
> that this has the same downsides as LD_LIBRARY_PATH.

In that case I guess your /etc/ld.so.conf doesn't include
/usr/local/pgsql/lib, but yes, if you want different binaries
to link different libraries you'll have to either use LD_LIBRARY_PATH
at runtime or -rpath at compile time.

> > Or do you see any -rpath line in the loader's Makefile ?
> There are no rpath's statically in the Makefile.  However, the
> Makefile does invoke ../libtool which dynamically adds rpath:
> libtool: link: gcc -g -O2 -fPIC -DPIC -Wall -Wmissing-prototypes
> shpopen.o dbfopen.o getopt.o shpcommon.o safileio.o pgsql2shp-core.o
> pgsql2shp-cli.o -o .libs/pgsql2shp  ../liblwgeom/.libs/liblwgeom.so
> -L/usr/lib64 -lgeos_c -lproj -lc -L/usr/local/pgsql/lib -lpq
> -Wl,-rpath -Wl,/usr/local/lib

Not here!

/bin/bash ../libtool --mode=link \
          gcc -g -O2  -fPIC -DPIC  -Wall -Wmissing-prototypes    shpopen.o dbfopen.o getopt.o shpcommon.o safileio.o pgsql2shp-core.o pgsql2shp-cli.o ../liblwgeom/liblwgeom.la -lc -L/usr/lib -lpq  -o pgsql2shp
libtool: link: gcc -g -O2 -fPIC -DPIC -Wall -Wmissing-prototypes shpopen.o dbfopen.o getopt.o shpcommon.o safileio.o pgsql2shp-core.o pgsql2shp-cli.o -o .libs/pgsql2shp  ../liblwgeom/.libs/liblwgeom.so -lc -L/usr/lib -lpq

> If I manually redo this part, changing "-Wl,/usr/local/lib"  to
> "-Wl,/usr/local/pgsql/lib", then I get the result I want--it finds the
> correct .so without the need for LD_LIBRARY_PATH.
> from looking at the output of running make, I see that the compilation
> of "postgis-2.0.so" does incorporate the settings of pg_config's
> output for LDFLAGS into the gcc call, which has the rpath:
> LDFLAGS = -Wl,--as-needed -Wl,-rpath,'/usr/local/pgsql/lib',--enable-new-dtags

Not mine...

-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -L/usr/lib/x86_64-linux-gnu -Wl,--as-needed

Mine is PostgreSQL 9.1.5

> Although I don't understand "make" well enough to figure out how it gets there.

I suspect the logic for that part is in PGXS.

> In any event, I'm not used to using LD_LIBRARY_PATH because other code
> I've used which links against PostgreSQL seems to use the rpath method
> to do so.  If postgis project doesn't want to change that, then maybe
> the README.postgis could include a section on "If you build PostgreSQL
> from source" with advice on that.

Feel free to provide a patch 


 http://www.cartodb.com - Map, analyze and build applications with your data

                                       ~~ http://strk.keybit.net 

More information about the postgis-devel mailing list