Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.