[15876] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: krb5 libraries and circular dependencies

daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Thu Jun 3 13:53:03 2010

In-Reply-To: <6DB13F8F-1584-4C31-BAF4-19FE58FADF6C@jpl.nasa.gov>
MIME-Version: 1.0
From: Jeffrey Hutzelman <jhutz@cmu.edu>
Date: Thu, 03 Jun 2010 13:41:39 -0400
To: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Message-ID: <c043d9fc-f2ed-456b-ac9b-43ef2dc5ee82@email.android.com>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu



"Henry B. Hotz" <hotz@jpl.nasa.gov> wrote:

> The example that sticks in my mind the most was
> Cyrus SASL.  The first time I built it on Solaris ldd said
> that the command line tools, and libsasl could find all
> their dependencies fine.  However libsasl couldn't
> find any of its plugins and had no mechanisms to
> offer.

I believe this is because on Solaris, the search for dependencies of a shared object loaded via dlopen() uses only the embedded path of the object being loaded, and not that of the object doing the load.  So, if the plugins depend on /usr/local/lib/libsasl.so.99 but don't have /usr/local/lib in RPATH, they won't load.

The build problem may or may not be related to the reason we patch libtool; I don't "own" sasl here and so don't know if we've seen that problem. Why libsasl doesn't warn when dlopen fails, I do not know.
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post