"Martin v. Loewis" <martin@v.loewis.de> writes:
OTOH, I cannot see what the problem might be - except that you will have to link with msvcr71.dll at the end, not with msvcrt40.dll.
There's an issue with mingw using malloc/free from msvcrt in its startup code - by the time msvcr71 gets linked in, the startup code has already resolved these two to msvcrt. I believe this is (nearly) resolved. Also, I've never seen a real problem caused by this, just dire hearsay about problems using incompatible runtimes...
If this hasn't been resolved, and somebody can send me a binary for a .NET-built Python, I'll be happy to test.
Sure: Please try my installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.msi
Does this install cleanly alongside a "production" Python 2.3? Ie, will it leave the meaning of the "python" command, and command line associations for .py files, etc, unchanged? As a test install, I'd like it to have no effect on my main Python (I have no test machine to install on separately).
Notice that this doesn't include msvcr71.dll, which I could provide in private.
Not a problem for me - I have this.
It also does not include msvcr71.lib - I have no clue how you would get a copy of that. But then, somehow, msvcrt40.lib (or is it msvcrt40.a) must have gotten into mingw32 also.
The appropriate library is indeed supplied with mingw. Paul. -- This signature intentionally left blank