Folks: I finally got around to doing some of this work:
On Mon, Jul 26, 2010 at 12:16 AM, Zooko O'Whielacronx <[email protected]> wrote: > > * http://tahoe-lafs.org/trac/pycryptopp/ticket/37# Win64 and MSVC9 > compilation fixes This might be fixed. If it isn't fixed, I think we need another buildslave which has the right compiler on it to demonstrate this problem. I'm not going to try to do any more work on it until then. > * http://tahoe-lafs.org/trac/pycryptopp/ticket/43# add a quick > start-up self test for SHA-256 Done. > * http://tahoe-lafs.org/trac/pycryptopp/ticket/44# test what happens > if another Python module loads Crypto++ dynamic link library Done, and the result is somewhat disturbing. Read the whole thread on the ticket (pycryptopp #44), but the disturbing result is that once I turn off the RTLD_GLOBAL hack then I can't reproduce any problem with RTTI crossing shared library boundaries. In particular we have unit tests that throw a C++ exception from libcryptopp.so and catch it in _pycryptopp.so, and this now works on all of our buildslaves. So perhaps we were using older versions of gcc a year ago and current versions have somehow fixed the problem. I'm not comfortable with that "grasping at straws" explanation, but I guess as long as I don't see evidence of a current problem we might as well move on. > * http://tahoe-lafs.org/trac/pycryptopp/ticket/45# upgrade to latest > Crypto++ with SHA-256 bugfixes Not yet done. I'm doing some more packaging, versioning, buildbot herding, etc., first. If someone wants to help, port raeburn's SHA-256 tests from http://sourceforge.net/apps/trac/cryptopp/ticket/2 to pycryptopp. Regards, Zooko -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
