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
--
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
Received on Fri May 05 2000 - 23:19:56 NZST