SUMMARY: shared library RPATH oddities

From: Tim Mooney <mooney_at_dogbert.cc.ndsu.nodak.edu>
Date: Sat, 06 May 2000 19:58:11 -0500 (CDT)

All-

I asked a question (included after my sig) about why the RPATH field in a
shared library wasn't letting the application that dlopen'ed it find other
shared libraries that it depends on.

I received a definitive response from Joe Mario of Compaq, one of the loader
developers. His response follows:

> The problem you're seeing is because the Tru64 loader does
> not use rpath on shared libraries. Specifically, this means
> if you have a shared library with -rpath set on it, when that
> shared library does a dlopen() call, the loader will not use
> any rpath that is set on the library.
>
> There are some technical reasons we haven't supported this
> (mostly dealing with loader performance). However, we recently
> decided we need to add this feature to the Tru64 loader real
> soon because of requests like yours. Expect to see it in
> an upcoming release.

Thanks to Joe, and to Tom Blinn for forwarding my question to him. I plan
on trying to link the Perl Authen::Krb5 module statically with the krb5
libraries, and see if that works (I expect it will).

Tim

-- 
Tim Mooney                              mooney_at_dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J1, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
My original question:
> All-
> 
> I've run into a problem involving multiple locally-built shared libraries,
> and it's caused me to doubt my understanding of how shared libraries, and
> particularly the RPATH field of a shared library, actually works on Tru64.
> I've thought for years that I understood the shared library details on
> Digital/Tru64 Unix, but that's apparently not the case...
> 
> System details:
> 
> Tru64 Unix v4.0f + patch kit #3
> perl 5.005_03 compiled with the system compiler
> Kerberos 5 version 1.0.6
> 
> I'm trying to build perl's Krb5 module, which is a perl5 interface to
> the Kerberos 5 API.  The build process generates and installs a shared object
,
> Krb5.so, that will be dlopen'ed by perl when a perl script that uses the
> Authen::Krb5 module is run.
> 
> I have the krb5 API shared libraries installed in `/local/krb5/lib'.  Each of
> the krb5 shared libraries was built with an RPATH field of `/local/krb5/lib'.
> Whenever I've linked a "normal" executable against any of those libraries,
> the executable has automatically picked up the RPATH field from the libraries
,
> so the loader can find them without requiring the use of LD_LIBRARY_PATH
> (which I abhor).
> 
> When the perl Krb5 module's Krb5.so is built, however, it *doesn't* pick up
> the RPATH to those libraries, which it requires (the NEEDED field lists
> three of the libraries that form the krb5 API, the Krb5.so shared object
> was built with ld using the `-expected_unresolved "*"' flag and the `-none'
> flag for those three libraries).
> 
> Because the Krb5.so didn't pick up the RPATH from the krb5 shared libraries,
> when I `use Authen::Krb5' in a script, the script fails because /sbin/loader
> can't find the shared libraries needed by Krb5.so.
> 
> Ok, fine, I thought.  I'll modify the build procedure for perl's Krb5.so
> shared object, to force the same RPATH into *it*.  That way it knows where to
> look for its shared libraries, since it didn't pick up the RPATH from them.
> That too does not work -- same `dlopen: cannot load' error message.
> 
> If I break down and set LD_LIBRARY_PATH to /local/krb5/lib , though,
> everything works.
> 
> Why didn't the shared object Krb5.so pick up the RPATH field from one of
> the libraries?  Is it because they're shared objects and not "normal
> executables", or because the libraries were linked `-none', or because of
> some other reason?  More importantly, why didn't explicitly setting an RPATH
> in the generated Krb5.so shared object work?
> 
> I'll happily provide more details (odump output, ld flags used when Krb5.so
> is built, or whatever) for anyone that asks, I just didn't want this message
> to get any longer than it already is.
> 
> Thanks,
> 
> Tim

Received on Sun May 07 2000 - 00:59:26 NZST