krb5 libraries and circular dependencies

[Henry B. Hotz]

On Jun 3, 2010, at 1:13 AM, Jeffrey Hutzelman wrote:

> --On Tuesday, June 01, 2010 12:30:06 PM -0700 "Henry B. Hotz" 
> <hotz at jpl.nasa.gov> wrote:
> 
>> 
>> On May 29, 2010, at 9:03 AM, krbdev-request at mit.edu wrote:
>> 
>>> On Fri, 28 May 2010 15:32:07 -0400
>>> Sam Hartman <hartmans at MIT.EDU> wrote:
>>> 
>>>> If the krb5 build system didn't use rpath, I think it would be fairly
>>>> unlikely that a plugin would get a different libkrb5 than the
>>>> application.  However, since rpath is used, I guess it is reasonably
>>>> easy to have this happen.
>>> 
>>> In some distributions rPath is forbidden exactly for these reasons, and
>>> needs an exception to be granted in order to be allowed for any single
>>> package.
>> 
>> My own experience has been that if you *don't* use rpath (or something
>> similar) then it's "fairly unlikely" that libkrb5 will find *any*
>> plugins.  That's doing custom builds, not OS integration of course.
> 
> Presumably this is because your plugins are built against libraries that 
> are not in the system default library search path.  The solution is to do 
> your custom builds "correctly", for whatever value of "correctly" makes it 
> work. :-)


I know it's always been an issue to pay attention to.

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.

Generally MacOS has seemed to d.t.r.t. more often than ELF with less trouble.  However I now have an issue where a pam module works fine, but won't load from within an authorization service plugin that calls the pam stack.  I have it on good authority that however "officially unsupported" it may be, it should work if the module is built right.  One of these days when I have lots of time. . .

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu