[postgis-devel] linkage against libpq.so (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
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
/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
-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
More information about the postgis-devel