configure not finding pointer-size integer types

[chrstphrchvz]

I have noticed this output during configure on both macOS and Linux:

checking for intptr_t... no
checking for pointer-size signed integer type... none
checking for uintptr_t... no
checking for pointer-size unsigned integer type... none

At a glance, this seems concerning since these systems do have intptr_t/uintptr_t. config.log shows the problem is escaped arguments in $CFLAGS being passed to the compiler. Example errors from clang:

configure:11242: checking for intptr_t
configure:11242: clang -c -pipe  -arch x86_64 ${CFLAGS_DEFAULT} ${CFLAGS_WARNING} ${SHLIB_CFLAGS}  conftest.c >&5
clang: error: no such file or directory: '${CFLAGS_DEFAULT}'
clang: error: no such file or directory: '${CFLAGS_WARNING}'
clang: error: no such file or directory: '${SHLIB_CFLAGS}'

Example errors from GCC:

configure:11242: checking for intptr_t
configure:11242: gcc -c  -pipe ${CFLAGS_DEFAULT} ${CFLAGS_WARNING} ${SHLIB_CFLAGS} conftest.c >&5
gcc: warning: ${CFLAGS_DEFAULT}: linker input file unused because linking not done
gcc: error: ${CFLAGS_DEFAULT}: linker input file not found: No such file or directory
gcc: warning: ${CFLAGS_WARNING}: linker input file unused because linking not done
gcc: error: ${CFLAGS_WARNING}: linker input file not found: No such file or directory
gcc: warning: ${SHLIB_CFLAGS}: linker input file unused because linking not done
gcc: error: ${SHLIB_CFLAGS}: linker input file not found: No such file or directory

These arguments ${CFLAGS_DEFAULT} ${CFLAGS_WARNING} ${SHLIB_CFLAGS} are added by TEA_MAKE_LIB in tcl.m4:

tkdnd/tclconfig/tcl.m4

Lines 3266 to 3271 in 6efca37

	# These are escaped so that only CFLAGS is picked up at configure time.
	# The other values will be substituted at make time.
	CFLAGS="${CFLAGS} \${CFLAGS_DEFAULT} \${CFLAGS_WARNING}"
	if test "${SHARED_BUILD}" = "1" ; then
	CFLAGS="${CFLAGS} \${SHLIB_CFLAGS}"
	fi

It seems like a solution would be to move the PTR2INT section in configure.ac to somewhere before TEA_MAKE_LIB. But I am not aware if TkDND has ever actually used PTR2INT/INT2PTR, so maybe this issue is harmless, and the PTR2INT section can just be removed instead.