Win64 and MSVC9 compilation fixes

[sneves]

The Microsoft compilers for AMD64 no longer support inline assembly. Thus, the amd64 version of crypto provides some separate assembly (.asm) files, which one must include in the compilation.

The inclusion of the two extra assembly files in turn requires the presence of a few more files. All in all, the following files are missing from the cryptopp/ directory:

x64dll.asm
serpent.cpp
serpent.h
serpentp.h
sosemanuk.cpp
sosemanuk.h

The file sha256module.cpp file also needs a minor correction, due to const correctness. Patch attached.

Attached in the patch to setup.py for the inclusion of the .asm files in the building process. This also requires a patched disttools package, for which a patch has already been submitted as well.

[zooko]

fixed by [20100604055652-92b7f-4109bb5fa23fc2015cb0227f37455393e01fe98d]

[zooko]

Hm, actually the build still fails on Samuel's buildslave:

​http://tahoe-lafs.org/buildbot-pycryptopp/builders/Dcoder%20Win7-64%20py2.6/builds/7/steps/compile/logs/stdio

ending with:

_pycryptoppmodule.obj : warning LNK4197: export 'init_pycryptopp' specified multiple times; using first specification
   Creating library build\temp.win-amd64-2.6\Release\cryptopp\_pycryptopp.lib and object build\temp.win-amd64-2.6\Release\cryptopp\_pycryptopp.exp
integer.obj : error LNK2019: unresolved external symbol Baseline_Add referenced in function "void __cdecl CryptoPP::RecursiveMultiply(unsigned __int64 *,unsigned __int64 *,unsigned __int64 const *,unsigned __int64 const *,unsigned __int64)" (?RecursiveMultiply@CryptoPP@@YAXPEA_K0PEB_K1_K@Z)
integer.obj : error LNK2019: unresolved external symbol Baseline_Sub referenced in function "void __cdecl CryptoPP::RecursiveMultiply(unsigned __int64 *,unsigned __int64 *,unsigned __int64 const *,unsigned __int64 const *,unsigned __int64)" (?RecursiveMultiply@CryptoPP@@YAXPEA_K0PEB_K1_K@Z)
rijndael.obj : error LNK2019: unresolved external symbol Rijndael_Enc_AdvancedProcessBlocks referenced in function "public: virtual unsigned __int64 __cdecl CryptoPP::Rijndael::Enc::AdvancedProcessBlocks(unsigned char const *,unsigned char const *,unsigned char *,unsigned __int64,unsigned int)const " (?AdvancedProcessBlocks@Enc@Rijndael@CryptoPP@@UEBA_KPEBE0PEAE_KI@Z)
sha.obj : error LNK2019: unresolved external symbol X86_SHA256_HashBlocks referenced in function "public: virtual unsigned __int64 __cdecl CryptoPP::SHA256::HashMultipleBlocks(unsigned int const *,unsigned __int64)" (?HashMultipleBlocks@SHA256@CryptoPP@@UEAA_KPEBI_K@Z)
_pycryptoppmodule.obj : error LNK2019: unresolved external symbol "void __cdecl init_sha256(struct _object *)" (?init_sha256@@YAXPEAU_object@@@Z) referenced in function init_pycryptopp
build\lib.win-amd64-2.6\pycryptopp\_pycryptopp.pyd : fatal error LNK1120: 5 unresolved externals
C:\Program Files\Python26\lib\site-packages\setuptools-0.6c11-py2.6.egg\setuptools\dist.py:284: UserWarning: Unbuilt egg for pycryptopp [unknown version] (c:\users\buildslave\builds\pycryptopp\dcoder_win7-64_py2.6\build)
error: command '"c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\link.exe"' failed with exit status 1120

I don't know if that is a consequence of this ticket or a separate ticket.

[zooko]

Oh I applied your patch wrong.

[zooko]

I added [20100604062512-92b7f-819c9866ab147a437686bbf411fe775eb0801f42], [20100604062944-92b7f-da87d3caf4936fc5b8d41300da593fca16cde6d5], and [20100604064001-92b7f-be84567f5cc85a7242daf75c984a1b8fe8dc25b3], but it still fails:

​http://tahoe-lafs.org/buildbot-pycryptopp/builders/Dcoder%20Win7-64%20py2.6/builds/10/steps/compile/logs/stdio

because invoking cl as a subprocess is apparently not a reliable way to detect that the compiler is MSVC, as shown here:

​http://tahoe-lafs.org/buildbot-pycryptopp/builders/Dcoder%20Win7-64%20py2.6/builds/10/steps/show-tool-versions/logs/stdio

Samuel: could you please supply a patch which detects whether the compiler is MSVC and uses the .asm only in that case?

(Hm, actually maybe the Right way to do this is to subclass a distutils class which is specific for MSVC or something?)

[zooko]

I suppose an even better solution would be to change setup.py​ to reliably detect whether the current compiler can correctly handle .asm files instead of trying to detect whether or not the compiler is MSVC9.

[zooko]

sneves:

As I think I mentioned to you on IRC, there is an idiom that is used in some setup.py files which is to attempt a build and then if it fails to fall back to a method of building which is more likely to work even if it produces less efficient results. This idiom is normally used for attempting to compile a C extension module and then falling back to a pure-Python implementation if the compilation fails, e.g.:

​http://code.google.com/p/simplejson/source/browse/trunk/setup.py?spec=svn231&r=230#sl_svn230_63

However, I guess the same approach would work to attempt to build .asm files and then fall back to excluding them if the attempt to compile fails. What do you think? It smells a bit too clever/magical to me, but on the other hand I do prefer testing whether we can do the thing we want to do over testing whether we have a certain version of a certain tool which can do that thing (i.e. whether we have a sufficiently new version of MSVC).

My discomfort about the magicalness of it could be eased if we inspected the exception that resulted from trying to build the .asm files and then proceeded to try to build without the .asm files only if the exception indicated that it was the .asm files that were the problem for the compiler.

What do you think?

[zooko]

<zooko> Dcoder: we would emulate this code:			        [13:58]
<zooko>
	http://code.google.com/p/simplejson/source/browse/trunk/setup.py?spec=svn231&r=230#sl_svn230_63
<Dcoder> looking at it
<zooko> 1. make a class which wraps build_ext and tries to detect the sort of
	failure that happens when you've tried to compile .asm files with a
	compiler that can't handle it, and turns that failure into a
	BuildFailed exception.
<zooko> 2. put a try: except: at the top-level of our setup.py which runs it
	with "try_asm=True", catches BuildFailed exception, and then runs it
	again with "try_asm=False".				        [13:59]
<zooko> It may also be a good idea to print out a warning message, like that
	setup.py does, although perhaps not as big of one. :-)

[zooko]

It is no longer clear to me that the current code is really problematic. There was a failure, described in comment:6, in build 10, but that may have been due to the Microsoft compiler being installed incorrectly on Samuel's buildslave. Not sure. If you, gentle reader, can devise a test of this code from setup.py, which ends with either "# We can handle out-of-line assembly." or "# We can't handle out-of-line assembly.", which test goes red on some of our buildslaves, then we'll know that we should go ahead and implement the hack described in comment:8 and comment:9.

Also, be aware that the Python distutils2 project intends to handle separate .asm files better in the future: ​http://bugs.python.org/issue7546