From looking at the headers you've made available, it looks like 
sys/_inttypes.h is always included, but it only defines the 64-bit 
types in some circumstances, namely when it doesn't define 
__STDC_32_MODE__; it defines that if __LP64__ is not defined (i.e., not 
a 64-bit build), and __cplusplus is not defined (i.e., plain C), and 
either __STDC__ is not defined (non-ANSI C build, which we're not going 
to do) or __STDC_EXT__ is defined.

So I guess the question is how to get __STDC_EXT__ defined.  In modern 
systems there's often a header that tests some compiler-defined flags 
for indicating desired standards compliance, and sets a bunch of other 
macros controlling which declarations get exposed by other headers.  
Looks like sys/stdsyms.h is the one for hpux 10.  I don't see it doing 
anything with __STDC_EXT__ except testing it, though, so this one may 
be a compiler-defined symbol.

Ah... first hit in google is a discussion on the gcc-bugs list about 
using __STDC_EXT__ with gcc 2.95.1, the reply claiming that the change 
to gcc had been made (for some future release, maybe 3.0?) to define 
__STDC_EXT__ unless the "-ansi" option is given.  Lenny, what version 
of gcc are you using?  If it's 2.95, try

   configure CPPFLAGS=-D__STDC_EXT__ --enable-static --disable-shared ...

(You might not need to disable the thread support; threads.c always 
gets compiled first, but just shouldn't do anything interesting after 
including some header files if the thread support is turned off, and it 
was the info on shared-library support in those headers that caused the 
failure the first time.)