FIX: Fixes the msvcr problem in MinGW

[certik]

See this thread for more information:

http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063381.html

I think this should go in before the release, because otherwise the sources don't build out of the box using MinGW. The 1.6.2 release builds just fine using the same Windows setup.

/cc @teoliphant, @charris, @rgommers

[travisbot]

This pull request fails (merged 76b1faf into f93774d).

[cournape]

I -1 on this as is. It is just removing code that does not work but used to. It may be an actual bug, but we don't know what it is.

[certik]

In the mailinglist thread (see above for a link), the bug seems to be that objdump can't read the msvcr.dll. What is the rationale to build such a library on our own? I think we need to do something, at least add a better error message, but I thought the suggestion on the mailinglist was to simply remove the code.

[cournape]

I cannot reproduce the issue, and confirmed that this change breaks the build. This fix is wrong.

[certik]

@cournape, thanks a lot for your time and the review.

Can you please post the log of the break? It looks like you have some different setup that I cannot reproduce. Which mingw version do you use? Do you use Wine or Windows (which one)?

Also, given your experience, what do you think would be a better fix?

[certik]

I must have misunderstood Nathan's suggestion to just remove the code: http://mail.scipy.org/pipermail/numpy-discussion/2012-July/063390.html

[cournape]

Ondrej: I used windows 7 64 bits (but use 32 bits python 2.7.3 and 32 bits toolchain). As for MinGW, I use the one given by the 5.0.4 installer referred by Ralf.

I don't think Nathan's is right, in the sense that the msvc runtime 9 import library is required whether we use localtime_s or not. Python 2.6 (and later, up to 3.2), require this version of the runtime, which is not included in the mingw version I used.

Unfortunately, using a more recent version for MinGW (using gcc 4.x) is not very practical for an installer, because it requires the deployment of additional dlls. Deploying shared dlls on windows is a big PITA: the only one I know is to add the dll in the python directory, which is very ugly. I don't know of any other solution for windows XP/Vista (windows 2008 and 7 have a way to support this).