"Martin v. Loewis" <martin at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4