Blame SOURCES/postgresql-perl-rpath.patch

ca36e9
We configure Postgres with --disable-rpath because for the most part we
ca36e9
want to leave it to ldconfig to determine where libraries are.  However,
ca36e9
for some reason the Perl package puts libperl.so in a nonstandard place
ca36e9
and doesn't add that place to the ldconfig search path.  I think this
ca36e9
is a Perl packaging bug, myself, but apparently it's not going to change.
ca36e9
So work around it by adding an rpath spec to plperl.so (only).
ca36e9
Per bug #162198.
ca36e9
ca36e9
ca36e9
diff -Naur postgresql-9.1.5.orig/src/pl/plperl/GNUmakefile postgresql-9.1.5/src/pl/plperl/GNUmakefile
ca36e9
--- postgresql-9.1.5.orig/src/pl/plperl/GNUmakefile	2012-08-14 18:41:04.000000000 -0400
ca36e9
+++ postgresql-9.1.5/src/pl/plperl/GNUmakefile	2012-08-17 11:15:09.457116708 -0400
ca36e9
@@ -43,6 +43,9 @@
ca36e9
 
ca36e9
 SHLIB_LINK = $(perl_embed_ldflags)
ca36e9
 
ca36e9
+# Force rpath to be used even though we disable it everywhere else
ca36e9
+SHLIB_LINK += $(rpath)
ca36e9
+
ca36e9
 REGRESS_OPTS = --dbname=$(PL_TESTDB) --load-extension=plperl  --load-extension=plperlu
ca36e9
 REGRESS = plperl plperl_lc plperl_trigger plperl_shared plperl_elog plperl_util plperl_init plperlu plperl_array
ca36e9
 # if Perl can support two interpreters in one backend,