I've just noticed that plperl is broken on my new Fedora installation:
[EMAIL PROTECTED] 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
...
[EMAIL PROTECTED] 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 form
rpath = -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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
