Dear List,
                   I just tripped up over this: I have just built and
installed Apache-2.0.54 (supplying libgssapiv2.so), but it
has been installed in a slightly old-fashioned style, divided
between /usr/inc, /usr/lib, /usr/bin, &c. As such, I can't
usefully specify --with-gssapi, but I can and do specify
--with-gssapi-includes and --with-gssapi-libs. However,
this doesn't work with the current version of 'configure'.
I have actually used this with curl-7.13.2, but there have
been no relevant changes to 'configure' in curl-7.14 .
Note that I have changed -lgssapi to -lgssapiv2 in what
follows, to correspond to what I actually did.

I am not submitting this as a formal patch script, because
I'd like to provoke some thought about what ought to
be happening!

The script currently reads

  if test -z "$GSSAPI_LIB_DIR"; then
     if test -f "$GSSAPI_ROOT/bin/krb5-config"; then
        gss_ldflags=`$GSSAPI_ROOT/bin/krb5-config --libs gssapi`
    LDFLAGS="$LDFLAGS $gss_ldflags"
     elif test "$GSSAPI_ROOT" != "yes"; then
        LDFLAGS="$LDFLAGS -L$GSSAPI_ROOT/lib$libsuff -lgssapi"
     else
        LDFLAGS="$LDFLAGS -lgssapi"
     fi
  else
     LDFLAGS="$LDFLAGS $GSSAPI_LIB_DIR"
  fi

I think that $libsuff is a stray bit of nonsense. Even if it does
make sense sometimes, surely it doesn't belong as a decoration to
the pathname of a parent directory?

I am also surprised that $GSSAPI_LIB_DIR seems to be a set of linker
flags. It's inherited from the calling environment (well, it *could* be
a shell
variable if 'configure' were invoked with 'source', but who does that?),
but it seems to have been confused with GSSAPI_LIBS, which has been
explicitly constructed inside 'configure' as a full set of linker flags,
despite its name. Maybe it should be called something else?
I am quite, quite sure that anything explicitly set in the
arguments to 'configure' ought to override GSSAPI_LIB_DIR, which
must be inherited from the environment
I propose, as my best guess at what ought to happen:

if test -n "$GSSAPI_LIBS"; then
    gss_ldflags="$GSSAPI_LIBS"
elif [ -n "${GSSAPI_ROOT+set} ] && [ -f "$GSSAPI_ROOT/bin/krb5-config
--libs gssapiv2 > /dev/null 2>/dev/null ] ; then
    gss_ldflags="`$GSSAPI_ROOT/bin/krb5-config --libs gssapiv2`"
elif krb5-config --libs gssapi > /dev/null 2>/dev/null ; then
    gss_ldflags="`krb5-config --libs gssapiv2`"
elif test X"$GSSAPI_ROOT" != 'Xyes'; then
    gss_ldflags="-L$GSSAPI_ROOT/lib -lgssapiv2"
elif test -n "$GSSAPI_LIB_DIR"; then
    gss_ldflags="-L$GSSAPI_LIB_DIR -lgssapiv2"
else
    gss_ldflags=-lgssapiv2
fi
LDFLAGS="$LDFLAGS $gss_ldflags"

That is, take it as specified: failing that, try to get krb5-config to
specify it, and try via GSSAPI_ROOT first, then the path.
If all fails, try a value relative to GSSAPI_ROOT (if specified),
otherwise just hope to find it in the default locations.

Compare and constrast the rules given for the #include search paths:
(unsurprisingly, no parallel to GSSAPI_LIB_DIR exists):

  if test -z "$GSSAPI_INCS"; then
     if test -f "$GSSAPI_ROOT/bin/krb5-config"; then
        GSSAPI_INCS=`$GSSAPI_ROOT/bin/krb5-config --cflags gssapi`
     elif test "$GSSAPI_ROOT" != "yes"; then
        GSSAPI_INCS="-I$GSSAPI_ROOT/include"
     fi
  fi
  CPPFLAGS="$CPPFLAGS $GSSAPI_INCS"

I naturally prefer

if test -z "$GSSAPI_INCS"; then
  if [ -n "${GSSAPI_ROOT+set} ] && [ -f "$GSSAPI_ROOT/bin/krb5-config
--libs gssapi > /dev/null 2>/dev/null ] ; then
    gss_cflags="`$GSSAPI_ROOT/bin/krb5-config --cflags gssapi`"
elif krb5-config --libs gssapi > /dev/null 2>/dev/null ; then
    gss_ldflags="`krb5-config --cflags gssapi`"
elif test X"$GSSAPI_ROOT" != 'Xyes'; then
    gss_ldflags="-I$GSSAPI_ROOT/include"
  fi
fi
CPPFLAGS="$CPPFLAGS $GSSAPI_INCS"

Any thoughts? Violent disagreement? Patient explanations that I've
missed the point entirely?

BTW, I've got cURL to link happily with libgssapiv2.so from Apache 2.054
simply by replacing 'lgssapi' with 'lgssapiv2'.

Bernard Leak

--
Before they made me, they broke the mould.