Now I'm really confused.

After linked /usr/bin/python to python3.3  :

  $ cd /usr/bin; rm -f python; ln -s python3.3 python;

the 2.7.1 build now succeeds ! 
(with the patched Lib/test/test_commands.py and the 'make test'
 run as non-root ).
This time I don't get any build errors for missing modules
and don't have to edit Module/Setup .
BTW, the missing modules that caused the build to fail before
was :
    'bsddb185 dl gdbm imageop'
; after the new ./python executable was built, it did some 
'configure modules' stage which DID fail with these missing
modules, but now /usr/bin/python is python3.3, it DOESN'T fail.

I don't think the current state of the installed system python
should be able to affect in any way the build of a new python -
that to me is a fundamental, critical bug in the build system.

Maybe I should open a new bug on that issue ?

But yes, the issue of this specific bug is now closed -
python-2.7.1 now builds OK - but PLEASE, put these 
lines or something like them in dlmodule.c :

#if __LONG_MAX__ > 0xffffffffU /* cpp -dM  builtin : __LONG_MAX__ */
#error dlmodule only works in 32-bit mode.
#endif