#72 closed defect (duplicate)
hang in SHA-256 self-test on Windows
Reported by: | davidsarah | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Version: | 0.5.19 | Keywords: | sha256 windows |
Cc: | Launchpad Bug: |
Description
When using the prebuilt pycryptopp-0.5.29-py2.7-win32.egg hosted at tahoe-lafs.org, the start_up_self_test for SHA-256 would hang at the first call to digest() here. Rebuilding the egg using Visual Studio 2008 Express (with Windows updates applied) caused this problem to go away. The new egg has now been copied to http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-dep-eggs/pycryptopp-0.5.29-py2.7-win32.egg , and the broken one is at http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-dep-eggs/pycryptopp-0.5.29-py2.7-win32.egg.broken .
I don't know whether any of the other pycryptopp eggs are similarly broken.
Note that the symptoms are very similar to the binutils-related bug http://tahoe-lafs.org/trac/tahoe-lafs/ticket/853 (caused by https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/461303 ). It is possible that the broken pycryptopp-0.5.29-py2.7-win32.egg was built with a broken version of gas, but I don't know how to confirm that.
If there were pycryptopp buildslaves building the eggs for Windows, they would automatically run the unit tests, which would have found this build problem. Building the eggs manually is very error-prone, and information about the build environment is lost. (Four buildslaves are needed: Python 2.6 and 2.7 for 32-bit and 64-bit Windows.)
Change History (2)
comment:1 Changed at 2011-07-18T01:43:47Z by davidsarah
- Resolution set to duplicate
- Status changed from new to closed
Duplicate of #73.