[15872] in Kerberos_V5_Development
Re: krb5 libraries and circular dependencies
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Thu Jun 3 04:13:36 2010
Date: Thu, 03 Jun 2010 04:13:29 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: "Henry B. Hotz" <hotz@jpl.nasa.gov>, krbdev@mit.edu
Message-ID: <F03D7440ED76F5257EB1E6C7@lysithea.fac.cs.cmu.edu>
In-Reply-To: <753B4070-B08F-484A-BE90-D7F0E4BDA768@jpl.nasa.gov>
MIME-Version: 1.0
Content-Disposition: inline
Cc: jhutz@cmu.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
--On Tuesday, June 01, 2010 12:30:06 PM -0700 "Henry B. Hotz"
<hotz@jpl.nasa.gov> wrote:
>
> On May 29, 2010, at 9:03 AM, krbdev-request@mit.edu wrote:
>
>> On Fri, 28 May 2010 15:32:07 -0400
>> Sam Hartman <hartmans@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. :-)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
