Making rpath a bit more flexible
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 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
Am Montag, 11. Oktober 2004 22:31 schrieb Tom Lane:
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.)
This is a bug in the operating system. It should be configured so that it can
find all libraries that it installs itself.
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)
I have no problem with that. But are there going to be cases where we need to
point to more than one library path?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
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)
I have no problem with that. But are there going to be cases where we
need to point to more than one library path?
Wouldn't it work to define rpathdir as "/foo:/bar:/baz" ?
regards, tom lane
Peter Eisentraut wrote:
Am Montag, 11. Oktober 2004 22:31 schrieb Tom Lane:
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.)This is a bug in the operating system. It should be configured so that it can
find all libraries that it installs itself.
The perl binaries know perfectly well where to find the library, because
they are built with its rpath, so normally there is no need to teach
ld.so where to find it.
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)I have no problem with that. But are there going to be cases where we need to
point to more than one library path?
Good point. If we come across that situation we'll have to do something
even more clever, Meanwhile, I like this.
cheers
andrew