Thread: 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 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

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