I've just noticed that plperl is broken on my new Fedora installation:
[tgl@rh1 plperl]$ make
...
gcc -O2 -fno-strict-aliasing -g -fpic -shared -Wl,-soname,libplperl.so.0 plperl.o spi_internal.o SPI.o
-L../../../src/port-L/usr/local/lib /usr/lib/perl5/5.8.5/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE-lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
-Wl,-rpath,/home/tgl/testversion/lib-o libplperl.so.0.0
...
[tgl@rh1 plperl]$ ldd libplperl.so.0.0 libperl.so => not found libnsl.so.1 => /lib/libnsl.so.1 (0x00878000)
...
The problem of course is that we have no rpath pointing to the place
where libperl.so lives. (Now that I look, the only reason this worked
before was that I had /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE
mentioned in /etc/ld.so.conf in my old installation.)
I think it would be a good idea to set up plperl.so with an rpath
pointing to the perl library directory; likewise for plpython.so and so
on. The only thing standing in the way is the platform-specific syntax
for setting rpath. We already have this in the makefiles, but it's
hardwired as (for Linux)rpath = -Wl,-rpath,$(libdir)
where libdir is our own library installation directory.
What I would like to do about this is change the platform-specific
makefiles to provide these macros in the formrpath = -Wl,-rpath,$(rpathdir)
rpathdir can be initialized to $(libdir) in Makefile.global and then
overridden in those Makefiles that want to use something different.
Any objections?
regards, tom lane