Re: libtool on solaris and hard coding the rpath

[libtool]

On Tue, Mar 13, 2001 at 11:13:24PM -0600, Tim Mooney wrote:
> 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.

What does your patch for Tru64 do? As far as I'm aware, up through
5.0A, the Tru64 linker does not honour RPATH entries in a library. So,
if you have program 'foo' linked to shared library 'libtest.so' which
depends on 'libsecond.so', and 'libsecond.so' is *not* in the standard
shared library search path, then you must set LD_LIBRARY_PATH to the
path where 'libsecond.so' is. IRIX, Solaris, and HP-UX work just fine.

Also, the Tru64 linker does *not* honour multiple -rpath command-line
arguments. Multiple paths must be fed to one -rpath argument separated
by a ':'. We wrote a tool, repld, that wraps ld to automatically join
multiple -rpath arguments that has really helped us out:
  http://freshmeat.net/projects/repld/

> 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.

Then *every* program libtool builds has the paths in LD_RUN_PATH
encoded.

-- 
albert chin (address@hidden)