Apologies - this time I remembered to attach the patches!

Dear List,
                  following my usual custom, I have sworn interminably over
curl's attempts (in 'configure') to determine curl_off_t. Is it just me, or
is this really a persistently fragile part of the configuration?
Also, as before, I find the inclusion paths broken when the build and
source directories are not the same. And it turns out that
--with-gssapi-libs doesn't work either.

Two patches are attached. They can also be found at
http://www.brenda-arkle.demon.co.uk/patches/curl/

(a) curl-7.15.5-sepbuild-1.patch

There are two distinct (and NOT equivalent) files called setup.h
(lib/setup.h and source/setup.h), each of which #include s config.h .
The assumption seems to be that this will always be in the same
directory as setup.h, and picked up from there. However, config.h
(both of them) are generated files, and if they aren't in the source
directory then they are searched for by way of the search path -
and that is unlikely to be correct for *both* possible locations for
setup.h, from *all* the places where they can be included.
That is, not only is it presently broken, but it's not clear that it can be
trivially un-broken. Bear in mind that lib/setup.h is included from
headers which are themselves sometimes included from src/somewhere.c.
And no, the two config.h files are not equivalent.

A half-hearted attempt has been made to solve the problem by adding
-I$(builddir)/../src (so at least src/config.h will be found), though no
corresponding effort has been made for -I$(builddir)/../lib. Indeed,
if we end up using the search path only the first one matters. It's
not quite clear that this is a mistake, though there is clearly a mistake
*somewhere*. Observe, however, that 'lib' sources are used from
'src', though the converse ought not to happen.

config.h is ONLY included via setup.h, and the Right Thing might well
be to re-name one or both of them, or to unite them as lib/config.h .
However, I've gone for a minimalist repair job. setup.h now include
the correct config.h explicitly by way of a partial path, as lib/config.h
or src/config.h, and $(top_builddir) is added to the 'include' search
path. Since I now have an anchor-point in the build directory, I also
use it for the other generated header file, ca_bundle.h (though of
course this isn't *necessary*, it lets me simplify some search paths).

I have modified the definitions of 'INCLUDES' in the Makefiles to be
complete, so they sometimes duplicate stuff in DEFAULT_INCLUDES.
This appears from 'nowhere' on the way from Makefile.am to Makefile.in .
If only I knew how to make them do what I want, I'd set
DEFAULT_INCLUDES to
-I$(srcdir) -I$(top_builddir) -I$(top_srcdir)/include
everywhere, and the duplicates could then be removed from INCLUDES.

This patch is a patch to the *release*, and it zaps Makefile.in files as
well
as Makefile.am . For convenience, the derived Makefile.in
files are patched at the END, so they can simply be snipped off to
produce a source-tree patch.

(b) curl-7.15.5-bl12-1.patch

The directory set with --with-gssapi-libs=<DIR> at configuration time
is simply thrown away! The widget which is actually used to hold
the directory is GSSAPI_LIB_DIR, but the value set is assigned to
GSSAPI_LIBS, which is not subsequently used. The patch replaces
GSSAPI_LIBS with GSSAPI_LIB_DIR .

Is there any chance of a 'proper' version which will find the
MIT krb5 gssapi library under its own name (libgssapi_krb5.whatever)
without requiring link fakery?

Again, configure is patched as well as configure.in, but the
patch for 'configure' is at the end, and can simply be snipped
off.

                                           Yours faithfully,

Bernard Leak.