According to this code in gdb/configure.ac, gdb requires long long support for building since gdb 7.7: ... if test "$gdb_cv_c_long_long" != yes; then # libdecnumber requires long long. AC_MSG_ERROR([Compiler must support long long for GDB.]) fi ... but AFAICT that's not documented anywhere (like, gdb/README). That means we can simplify gdb/python/python-internal.h, which still contains code for !HAVE_LONG_LONG.
Without looking at the older python configury, I guess it's possible in theory that the platform compiler has long long but somehow python was built without it?
(In reply to Tom Tromey from comment #1) > Without looking at the older python configury, I guess > it's possible in theory that the platform compiler has > long long but somehow python was built without it? I suppose it's possible, indeed, but I'm not sure either whether that situation is properly supported in gdb now. That is, if python doesn't define HAVE_LONG_LONG in pyport.h, but config.h does, I think it's still defined in python files, forcing the use of PY_LONG_LONG in python-internal.h, which will be undefined, which then should cause a compilation failure. Either way, the situation looks like an exception, so even if it would work somehow, I'm not sure it's worth bothering with.