Skip to contentSkip to conversation

libtirpc-0.3.1 fails to build with Heimdal Kerberos

DISCUSSION Karl-Johan Karlsson 2 participants 2 messages Jun 5, 2015

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hi,

I'm trying to debug a build failure for libtirpc-0.3.1 with GSSAPI support when using Heimdal 1.5.3 as Kerberos provider. Downstream bug report is at
https://bugs.gentoo.org/show_bug.cgi?id=551036

src/svc_auth_gss.c has an unconditional
#include <gssapi/gssapi_ext.h>
but Heimdal doesn't ship that file; MIT-Krb5 does, though. It looks like most (but not all) of the functions that MIT-Krb5 declares in <gssapi/gssapi_ext.h> are declared in Heimdal by <gssapi/gssapi.h>.

src/svc_auth_gss.c has
#ifdef HAVE_KRB5
and
#elif HAVE_HEIMDAL
sections, but nothing I can see in the Autoconf system defines those. configure.ac does have
AC_CHECK_HEADER([gssapi/gssapi.h], [HAVE_GSSAPI_H=yes], [HAVE_GSSAPI_H=no])
but that's just used internally in the configure script.

Would it be correct to export HAVE_GSSAPI_H and HAVE_GSSAPI_EXT_H to config.h and have src/svc_auth_gss.c include gssapi.h and/or gssapi_ext.h depending on them?

By the way, the link to the libtirpc gitweb on http://linux-nfs.org/wiki/index.php/Main_Page is broken. It points to http://git.linux-nfs.org/?p=steved/libtirpc.git;a=summary which is a 404.

Signature · 1 line
Karl-Johan Karlsson
#1 lore raw
Quoted 12 lines · Karl-Johan Karlsson

Hi,

I'm trying to debug a build failure for libtirpc-0.3.1 with GSSAPI support when using Heimdal 1.5.3 as Kerberos provider. Downstream bug report is at
https://bugs.gentoo.org/show_bug.cgi?id=551036

src/svc_auth_gss.c has an unconditional
#include <gssapi/gssapi_ext.h>
but Heimdal doesn't ship that file; MIT-Krb5 does, though. It looks like most (but not all) of the functions that MIT-Krb5 declares in <gssapi/gssapi_ext.h> are declared in Heimdal by <gssapi/gssapi.h>.

Quoted 5 lines

src/svc_auth_gss.c has
#ifdef HAVE_KRB5
and
#elif HAVE_HEIMDAL
sections, but nothing I can see in the Autoconf system defines those.

Looks like that’s dead code. But it’s just a debugging message, so no harm. Should be cleaned up, eventually.

Quoted 7 lines

configure.ac does have
AC_CHECK_HEADER([gssapi/gssapi.h], [HAVE_GSSAPI_H=yes], [HAVE_GSSAPI_H=no])
but that's just used internally in the configure script.

Would it be correct to export HAVE_GSSAPI_H and HAVE_GSSAPI_EXT_H to config.h and have src/svc_auth_gss.c include gssapi.h and/or gssapi_ext.h depending on them?

Using the HAVE_GSSAPI_* macros in src/*.c is just fine. You’ll have to introduce an AC_CHECK for gssapi_ext.h in configure.ac.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com