The compile barfs like this:
In file included from ../../gdb-5.2/gdb/thread-db.c:26:
../../gdb-5.2/gdb/gdb_thread_db.h:211: parse error before `uintptr_t'
../../gdb-5.2/gdb/gdb_thread_db.h:211: warning: no semicolon at end
of struct or union
../../gdb-5.2/gdb/gdb_thread_db.h:211: warning: no semicolon at end
of struct or union
../../gdb-5.2/gdb/gdb_thread_db.h:212: warning: type defaults to
`int' in declaration of `msg'
../../gdb-5.2/gdb/gdb_thread_db.h:212: warning: data definition has
no type or storage class
../../gdb-5.2/gdb/gdb_thread_db.h:213: parse error before `}'
This could be detected at autoconf time, something like:
AC_MSG_CHECKING(for uintptr_t support in glibc)
AC_CACHE_VAL(ac_cv_c_uintptr_t,
[AC_TRY_COMPILE(, [
#include <stdint.h>
uintptr_t foo;
],
ac_cv_c_uintptr_t=yes, ac_cv_c_uintptr_t=no)])
AC_MSG_RESULT($ac_cv_c_uintptr_t)
if test $ac_cv_c_uintptr_t = yes; then
AC_DEFINE(HAVE_UINTPTR_T)
fi
Then gdb_thread_db.h could produce a better error message if it
gets compiled. It's used only on *-*-*linux* and s390-*-*,
not everywhere.
Do you want to go in that direction? That looks reasonable to me.
I would balk at actually filling in a defintion of uintptr_t though.
If their glibc is that old (3 years old!) they are likely to have
other problems and I want to cauterize their build.
Michael C