> I happen to know, for example from the > Windows buildbot that we run -- http://allmydata.org/buildbot/ > waterfall -- that mingw can reliably build modules for Python 2.5.
Yes, the problem is only with 2.6 and later versions that moved to use VS2008 (and depend on MSVCR90.dll as a result). > Now as to your current problem with pycryptopp -- I suppose this is > because the one on the testgrid was built (by me) with mingw. Maybe > we should try building it with MSVC? Or, per http://bugs.python.org/ > issue3308 , perhaps we just need to remove all uses of 'localtime'? > Uh-oh, grep tells me that there are no instances of 'localtime' in > _pycryptopp.pyd. Hm. I've traced the problem to the 'time' symbol that is missing from msvcr90.dll but mingw thinks it should be there. I've fixed my local libmsvcr90.a so mingw sees that it has no 'time' in it and imports it from msvcrt.dll instead - this makes pycryptopp build and work fine. I'm not sure this is the right long term solution (importing both msvcr90 an msvcrt is not good i think), I'll check how microsoft compilers handle the symbols removed from msvcr90.dll when I'm back at my work (don't have them installed here) but that will be only next week. For now if anyone is interested here's a list of other symbols that mingw thinks are in msvcr90.dll but in reality they are missing: http://testgrid.allmydata.org:3567/file/URI%3ACHK%3Ak4vunoigyr4yuzwm2nbxog6hhu%3Apl4x6frwl4icgelr2cdjnbodo3qij3p7bg6qdxlmptjrfefvoxyq%3A3%3A10%3A550/@@named=/msvcr90-missing-exports.txt And a working libmsvcr90.a replacement (generated from the real DLL) - this seems to be needed to produce working binaries that use msvcr90.dll (e.g. python>=2.6 extensions) using mingw: http://testgrid.allmydata.org:3567/file/URI%3ACHK%3A7pkqvkym72z2tv663mfsljm3we%3Afq2xs6xcaszjquiqi2hequ6crulmzrvn3ne2c2rm6fiy7vpyfuoa%3A3%3A10%3A36268/@@named=/fixed-libmsvcr90.rar With this and my problem with libpython26.a solved (which turned out to be because i was using ActiveState distribution of python but following documentation for the python.org distribution) i can do a full build of tahoe+dependencies for python 2.6 with mingw both from the last realease and current code from darcs. I've also ran the tests after building from darcs, most was successful, except for 3 tests related to the recent epoch changes, full log here: http://testgrid.allmydata.org:3567/file/URI%3ACHK%3Aeh4c2m2ibay56ges5d5ajtzu5a%3Ah64jk2eraeat5j52umzvfy3sta6erngahulng4kperqe3cvhmndq%3A3%3A10%3A63995/@@named=/tahoe-r3913-tests.txt > Would you like to contribute a buildbot? This would entail letting > the Tahoe project run builds on your Windows computer so that we can > track progress of building for Python 2.6 with mingw and/or msvc Well, the computers where i could install a buildbot are not online 24/7 and have a crap internet connection, if that is ok i can set up a build bot to build with mingw (and maybe a debian unstable one too, saw you mention it on the 1.5.0 thread) _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
