I have an Itanium Linux system where compiling Python's _ssl module fails for some reason, with the consequence that there is no md5 support at all in the resulting Python 2.7.5 installation.

With Python 2.7.4, setup.py didn't even try to compile _ssl, instead it compiled the _sha, _md5, _sha256, _sha512 modules and it worked.

With Python 2.7.5, setup.py somehow thinks that _ssl should work, tries to compile _ssl, which fails and (this is the real failure): it doesn't try anymore to compile the _sha, _md5, _sha256, _sha512 modules.

setup.py doesn't compile _md5 and the other C extension if it thinks that _ssl is available. Can you post the build error of the _ssl module here, too?

Sure, building _ssl fails with:
building '_ssl' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -I. -IInclude -I./Include -I/usr/include -I/home/buildbot/build/sage/iras-1/iras_full/build
/sage-5.10.beta4/local/include -I/home/buildbot/local/iras/include -I/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0/src/Inc
lude -I/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0/src -c /home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.bet
a4/spkg/build/python-2.7.5.p0/src/Modules/_ssl.c -o build/temp.linux-ia64-2.7/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0
/src/Modules/_ssl.o
gcc -pthread -shared -L/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/local/lib -L/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/loc
al/lib build/temp.linux-ia64-2.7/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0/src/Modules/_ssl.o -L/usr/lib -L/lib -L/home
/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/local/lib -L/home/buildbot/local/iras/lib -L. -lssl -lcrypto -lpython2.7 -o build/lib.linux-ia64-2.7/_ssl.so
/usr/bin/ld: /home/buildbot/local/iras/lib/libcrypto.a(obj_dat.o): @gprel relocation against dynamic symbol obj_cleanup_defer
/usr/bin/ld: /home/buildbot/local/iras/lib/libcrypto.a(obj_dat.o): @gprel relocation against dynamic symbol obj_cleanup_defer
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

But really: I think the main problem here is that _md5 isn't even attempted to build.

Yes, that's the main culprit. At first setup.py checks if all necessary bits and pieces for _ssl are available. If setup.py doesn't find the shared libraries and header files it adds _md5 to the list of extensions. Compilation and linking happens *after* the list of extension modules has been created.

This has been fixed for Python-3.3 in #14693. Attached is a straightforward Python-2.7.5 backport of the patch.

The other bug report classifies the request behavior as a new feature, so it could not go into 2.7.

The problem on the machine that I mentioned was a regression from 2.7.4 to 2.7.5, probably due to #17086. Whether you consider a patch a "bugfix" or "new feature" is quite subjective, right? If #17086 is a bugfix, then this can also be a bugfix.

Python 2.7 is reaching EOL soon and this bug has been dormant for over six years. Since the problem is solved in Python 3, I'm closing this bug as WONTFIX.