Gonzalo Monzón wrote: > I use Python 2.4.3 (msvcrt71) and I succesfully installed the last > version of binutils, pyrex and MinGW, some weeks ago, using Julien Fiore > step-by-step guide, so "my" MinGW is linking with msvcrt71.dll, with the > default configuration.
A successful build (compile and linkage) does not imply that you are linking with the same crt as Python. It just means that there are no syntax errors (successful compile) or unresolved external symbols (successful linkage) in your code. > I don't understand why do you say MinGW links with msvcrt.dll... perhaps > you've got an older version than the ones Julien posted? Because it does not! What happens is that MinGW links with the import library for msvcrt.dll. The compiler does not complain bacause there are no syntax errors. The linker does not complain bacuase there are no unresolved external symbols (after all, msvcrt is a standard crt). When you run your program, Windows search the search path for msvcrt.dll, finds the dll in c:\windows\system32, and loads it into your process image. This produces no errors either. So intitially everything seems to be ok. But... The process image for your Pyrex extension is shared with the Python interpreter. Previously, msvcrt71.dll was loaded into into the porcess image when Python started. Now both crts reside in the process, and Python and your Pyrex extension starts to call their respective crts. The crts interfere with each other and you get very unpredictable results. This is not just a Python problem. Microsoft created this problem when they started to publish multiple versions of their crt. Whenever a process has imported different crts, there will inevitably be run-time conflicts. Windows is a "component" based operating system. If you are e.g. using in proc COM objects (also known as "ActiveX Components"), you can only pray to God that the author did not use a different crt than you. If you are loading a precompiled DLLs, you can only pray to God that the author did not use a different crt than you. Previously this was not an issue, as Windows had exactly one shared crt. Now this is all messed up. Why did Microsoft decide to create "C runtime DLL Hell"? I have no idea. -- http://mail.python.org/mailman/listinfo/python-list
