Re: libtool on solaris and hard coding the rpath

[Tim Mooney]

In regard to: libtool on solaris and hard coding the rpath, Liam Hoekenga...:

>       % ldd libphp4.so
>        libpam.so.1 =>   /usr/lib/libpam.so.1
>        libdl.so.1 =>    /usr/lib/libdl.so.1
>        libsocket.so.1 =>        /usr/lib/libsocket.so.1
>        libnsl.so.1 =>   /usr/lib/libnsl.so.1
>        libresolv.so.2 =>        /usr/lib/libresolv.so.2
>        libm.so.1 =>     /usr/lib/libm.so.1
>        libclntsh.so.8.0 =>      (file not found)
>        libc.so.1 =>     /usr/lib/libc.so.1
>        libmp.so.2 =>    /usr/lib/libmp.so.2
>
>Is there any way to actually get libtool (on Solaris) to hardcode the
>rpath into shared libraries (in addition to any program binaries it might
>be used to generate)?

I'm not sure what the libtool maintainers policy on this particular issue
is, but I've always preferred to have the RPATH hardcoded into libraries
as well, especially on platforms like Tru64 UNIX and IRIX, where the apps
automatically pick up that RPATH when they link with the library (so you
don't need to worry about specifying an RPATH when you link the app, only
when you build the libraries).  Solaris is a bit more of a pain, but that's
Solaris.  :-)

I have a patch that really saves me some work with Tru64 and IRIX, but I'm
not sure it wins me anything on Solaris, since even if you build a DT_RPATH
into a library there, the apps generally don't pick it up from the library.

You do know about the LD_RUN_PATH environment variable that the Solaris
linker will honor, though, right?  You could use that to hardcode your
DT_RPATH with `libtool' being none the wiser, I think.

Tim