Re: libtool on solaris and hard coding the rpath

[Tim Mooney]

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

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

It depends on what you mean by honour, and whether you really mean linker,
or whether you're thinking of the loader.

1) Through at least 5.1, if you build an RPATH into a shared library and
that library depends on other shared libraries that might be in weird spots,
you essentially have to set LD_LIBRARY_PATH because the *loader* will not
use the RPATH in a shared library to search for other shared objects the
library depends on.

2) Through at least 5.1 and going back to the very early days, if you build
a shared library with an rpath in it and then link any application to
that shared library, the linker automatically adds the RPATHs from all
shared libraries used at link time into the application.  This means
that if you've built your shared libraries with RPATHs, you never need to
mess with RPATHs with your applications themselves, because the linker
will automatically propagate the RPATHs into the applications.  The linker
also takes care of RPATH "reduction", i.e. making sure that any particular
path appears only once in the RPATH list for a particular application.

This essentially means that with current behavior (which is scheduled
to change so that both #1 and #2 are true) on Tru64, RPATHs are used as
hints for applications, not hints for shared libraries.  RPATH existence
in a shared library is something useful to the application, not something
useful to the shared library itself *or* to other shared libraries that
are linked against it.  It's only applications that benefit, currently.

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

That is correct, because of #1) and the behavior of the *loader*.

> IRIX, Solaris, and HP-UX work just fine.

Solaris, at least, has a linker that doesn't do #2, AFAICT.  IRIX and
Tru64 are otherwise very very similar, but you're right about the
difference being in #1.

>Also, the Tru64 linker does *not* honour multiple -rpath command-line
>arguments. Multiple paths must be fed to one -rpath argument separated
>by a ':'.

Correct.

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

Nice, that might be helpful.  Thanks for the pointer.

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

That is correct, but the idea is you set it right before you build the program,
and don't keep it around afterward, unless you have just a few standard
directories that need to be searched, in which case you might be lazy and
just leave it in your environment all the time.

With Solaris 8, this should be moot, since it has a concept similar to Linux's
ld.so.cache.

Tim
-- 
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J1, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164