Pyrex installation on windows XP: step-by-step guide

[sturlamolden]

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.