[tahoe-dev] Windwos installation problems

Black Dew blackdew at gmail.com
Fri Jun 12 04:58:17 PDT 2009


> 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)


More information about the tahoe-dev mailing list