The reason it failed in sles11sp1 but not sles11sp2 is
sles11sp1:
checking for gss_export_lucid_sec_context in -lgssapi... no
checking for gss_export_lucid_sec_context in -lgssglue... yes <<<<
sles11sp2:
checking for gss_export_lucid_sec_context in -lgssapi... no
checking for gss_export_lucid_sec_context in -lgssglue... no
I believe the logic in the patch
AC_CHECK_LIB([gssapi], [gss_export_lucid_sec_context],
[GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssapi";
gss_conf_test='success'],
[AC_CHECK_LIB([gssglue], [gss_export_lucid_sec_context],
[GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssglue";
gss_conf_test='success'],
[if test x$enable_gss == xyes; then
AC_MSG_ERROR([libgssapi or libgssglue is not found, which is required by GSS.])
else
AC_MSG_WARN([libgssapi or libgssglue is not found, which is required by GSS.])
fi])],)
do we need both libgssapi and libgssglue to be yes or both to be no?
I'd say if we can't fine both krb5int_derive_key and krb5_derive_key, we will issue a warning and set HAVE_KRB5 to 0