On Tue, 2013-04-02 at 13:57 -0400, Steve Dickson wrote: > Again using git send-email to post your patches would make this > a lot easier... ;-) Will do from here on. > On 26/03/13 13:00, Simo Sorce wrote: > > Libgssglue is not really useful anymore, it is a sort of middleman that > > wraps the actual GSSAPI that is already pluggable/extensible via shared > > modules. > > > > In particular libgssglue interferes with the workings of gss-proxy in my > > case. > > > > The attached patch makes building against libgssglue optional and > > defaults to not build against libgssglue and instead builds directly > > against the native GSSAPI. > > > > ./configure --enable-gss > > will now build against GSSAPI > > > > ./configure --enable-gss --with-gssglue > > will keep building against libgssglue in case someone still needs it for > > whatever reason. > > > in he first patch you define HAVE_GSS_KRB5_FREE_LUCID_SEC_CONTEXT > which is good: > > --- a/aclocal/kerberos5.m4 > +++ b/aclocal/kerberos5.m4 > @@ -92,6 +92,8 @@ AC_DEFUN([AC_KERBEROS_V5],[ > AC_DEFINE(HAVE_SET_ALLOWABLE_ENCTYPES, 1, [Define this if the Kerberos GSS library supports gss_krb5_set_allowable_enctypes]), ,$KRBLIBS) > AC_CHECK_LIB($gssapi_lib, gss_krb5_ccache_name, > AC_DEFINE(HAVE_GSS_KRB5_CCACHE_NAME, 1, [Define this if the Kerberos GSS library supports gss_krb5_ccache_name]), ,$KRBLIBS) > + AC_CHECK_LIB($gssapi_lib, gss_krb5_free_lucid_sec_context, > + AC_DEFINE(HAVE_GSS_KRB5_FREE_LUCID_SEC_CONTEXT, 1, [Define this if the Kerberos GSS library supports gss_krb5_free_lucid_sec_context]), ,$KRBLIBS) > > dnl Check for newer error message facility > AC_CHECK_LIB($gssapi_lib, krb5_get_error_message, > > But in the second patch you use a non-existent define HAVE_LIBGSSGLUE. > Why not just use HAVE_GSS_KRB5_FREE_LUCID_SEC_CONTEXT? Because the mere fact the native GSSAPI library have that function is not the decisive factor we use to determine against what we want to compile. It's true that after I reordered patches the definition of HAVE_LIBGSSGLUE ended up in the 3rd patch, but that is a venial problem I hope. > --- a/utils/gssd/gss_util.h > +++ b/utils/gssd/gss_util.h > @@ -42,4 +42,14 @@ void pgsserr(char *msg, u_int32_t maj_stat, u_int32_t min_stat, > const gss_OID mech); > int gssd_check_mechs(void); > > +#ifndef HAVE_LIBGSSGLUE > +#include <gssapi/gssapi_krb5.h> > +#define gss_free_lucid_sec_context(min, ctx, ret) \ > + gss_krb5_free_lucid_sec_context(min, ret) > + > +#define gss_export_lucid_sec_context gss_krb5_export_lucid_sec_context > +#define gss_set_allowable_enctypes(min, cred, oid, num, types) \ > + gss_krb5_set_allowable_enctypes(min, cred, num, types) > +#endif > + > Personally I like the way Alex handled this in his patch better.. The way Alex handled it makes it impossible to build against libgssglue, and I have not removed libgssglue just made it optional. This way is not pretty but allows to still compile against libgssglue if needed. Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
