Using KfM's credentials cache with Krb5 1.3 on OS X 10.2.6

Steven Michaud smichaud at pobox.com
Wed Aug 13 17:15:33 EDT 2003


> No, Chas's original patch included unrelated changes to how shared
> libraries were built that had nothing to do with ccapi.

I assume you mean the stuff in shlib.conf.  My patch has a couple of
small non-ccapi changes there, too -- from LDCOMBINE I drop
"-undefined warning" and add "-bind_at_load".  The first change is
necessary -- it's incompatible with a two-level namespace.  (You could
replace it with "-undefined error", but since that's the default I
just left it out.)  Though the second is not a default, Apple's "ld"
loves to output warnings that recommend it.

> It's certainly your decision, and from your standpoint I think this
> is reasonable.  However, when people post patches to krbdev, if
> there are obvious reasons we'd reject them if they were filed as a
> bug, I try to point those out.

No problem.  A suggestion I disagree with is better than blank silence
:-)

On Wed, 13 Aug 2003, Sam Hartman wrote:

> >>>>> "Steven" == Steven Michaud <smichaud at pobox.com> writes:
>
>     >> IN particular, please remove the parts that add shared library
>     >> support for darwin.
>
>     Steven> I'm not sure what you're getting at here.
>
>     >> We are not ready to commit to an ABI on darwin and would be
>     >> very annoyed if a bunch of people were
>     >> distributing/using/expecting a particular shared library ABI.
>
>     Steven> Are you talking about the fact that my patch (as it now
>     Steven> stands) hard codes the name of the Kerberos framework?
>
> No, Chas's original patch included unrelated changes to how shared
> libraries were built that had nothing to do with ccapi.
>
>     Steven> To put it briefly, I don't see the point of complicating a
>     Steven> patch that, while it's now very useful, will be obsolete
>     Steven> in a few months.
>
> It's certainly your decision, and from your standpoint I think this is
> reasonable.  However, when people post patches to krbdev, if there are
> obvious reasons we'd reject them if they were filed as a bug, I try to
> point those out.
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>


More information about the krbdev mailing list