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

[Gonzalo Monzón]

Hi,

sturlamolden escribió:

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.
>  
>
Does this happen if you're releasing, i.e. a built exe with py2exe, 
where you supply the right crt? or if you do supply the right crt on the 
application folder? ... I see my pyrex extension imports with both, 
msvcrt and msvcrt71, and when I do execute the python program, I see 
with dependency tool that only msvcr71 gets loaded and I suppose no more 
crt's are loaded at runtime, as it is shared by my extension and the 
Python interpreter & std. extensions.

In a posterior email on this thread i asked about this issue:

I see there are both libraries linked in my pyrex modules...  However, 
when one should expect to have problems with this "dll nightmare", if 
you always provide the right msvcr71.dll bundled within your project -I 
mean, using py2exe by example- ?

Of course if you didn't bundle the right crt, it does depend on the 
available crt on target system... then you would be in trouble if user 
doesn't have msvcrt71, or anyway, could be in trouble linking the 
"right" library?

Thanks for any explanation.

Regards,
Gonzalo


>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.
>  
>
Why msvcrt is being loaded later than msvcrt71? why both dll are being 
loaded it migw links to both and one is already loaded by python 
interpreter? perhaps the only way to achieve total reliability is to 
compile using the same where Python & standard extensions where 
compiled? In the case, does any sense to compile using mingw for 
standard python >= 2.4 custom extensions?

>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.
>
>  
>
I'm aware of this, but I am not about every detail.

Regards,
Gonzalo