Hi Phil ,

> > /* curl_off_t formatting string directive without "%" conversion specifier. */
> > #define CURL_FMT_OFF_T "ll d"
>
> >From a quick look at the patch I would guess the problem is here:
>
> + x_format=`echo "$x_format" | "$SED" 's/[["]]//g'`
>
> The format that gets fed into this will be something like PRId64 from
> <inttypes.h>, which expands to "l" "d" (with a space in the middle).
> So, just naively stripping off the quote marks still leaves you with the
> space. I guess you need to fiddle the sed expression a bit to ditch
> whitespace as well.

Aha! I didn't expect PRId64 to be several double quoted strings.

This introduces something quite nasty when that succession of double
quoted strings is assigned to a shell variable.

Where you see: x_format=AS_VAR_GET([tmp_Def])
it must be doing something like: x_format="ll" "d"

Which must be the reason for what other logs are exhibiting the following:

checking for 64-bit curl_off_t data type... ../curl/configure:
curl_cv_have_def_PRId64=yes: command not found
../curl/configure: curl_cv_def_PRId64="ll": command not found

We need to get rid of the spaces and the inner quoting before it is
assigned to a shell variable.

How fun.

-- 
-=[Yang]=-