GSSAPI library compatibility between MIT releases

[Cesar Garcia]

Thank you. 

>>>>> "Sam" == Sam Hartman <hartmans at MIT.EDU> writes:

>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:
Cesar> Thanks Sam - two more question (below)
>>>>> "Sam" == Sam Hartman <hartmans at MIT.EDU> writes:

>>>>> "Cesar" == Cesar Garcia <Cesar.Garcia at morganstanley.com> writes:
Cesar> I was wondering if someone from MIT can make a statement
Cesar> regarding library/binary compatibility from one release to
Cesar> the next of the GSSAPI libraries - I won't ask about
Cesar> libkrb5 and related libs.

Sam> To my knowledge, MIT has not broken ABI compatibility since
Sam> before 1.2.0 for libkrb5, libk5crypto, or libgssapi_krb5 on
Sam> Unix.  We have not broken ABI compatibility since KFM 4.5 or
Sam> KFW 2.5.  I actually believe the constraints for KFW and KFM
Sam> are much wider than that, but I know those are true.

Cesar> Considering statement in last paragraph below, does this
Cesar> then also apply to lib_comerr?

Sam> More or less.  We are certainly committed to stable com_err, although
Sam> it may have broken more recently than the other libraries.  It has not
Sam> broken since 1.2.5 and possibly has been stable much longer than that.

Sam> We've decided that the public API (what you get from krb5.h,
Sam> That said, our efforts to make the ABI stable may not be
Sam> enough.  You need to look at the stability of all the
Sam> libraries that you link against directly or indirectly when
Sam> you pull in Kerberos.  If those don't have particularly
Sam> stable ABIs, they may create problems for running old
Sam> Kerberos applications.

Cesar> One last question (which shows my ignorance on this
Cesar> subject), if I'm always linking with a set of libraries
Cesar> from the *same* MIT release (that is e.g., I don't mix
Cesar> 1.3.1 libgssapi_krb5 and 1.2.8 libkrb5) and my app's only
Cesar> lib dependency is libgssapi_krb5 (and I only reference
Cesar> symbols from libgssapi_krb5), need I worry about say an ABI
Cesar> change to libkrb5 in such a case? (I would suspect not, but
Cesar> like I said, I'm somewhat ignorant on this matter).

Sam> An ABI change to libkrb5, probably not.  But no such application
Sam> exists.  You probably call C library functions like gethostbyname, may
Sam> call the same regex library we do, etc.  As we start adding
Sam> internationalization support to our libraries, twe will increase the
Sam> set of dependencies our libraries have.  If your applications has
Sam> intersecting dependencies, and one of those dependencies changes its
Sam> ABI, then either your application or our library may break if linked
Sam> into the same address space.

Sam> All depends or on a complex mess of platform dependencies like
Sam> versioned symbols, shared library linker options, etc.