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

[Julien Fiore]

Do you wand to install Pyrex on Windows ?

Here is a step-by-step guide explaining:

A) how to install Pyrex on Windows XP.
B) how to compile a Pyrex module.

Julien Fiore,
U. of Geneva

-------------------------------------------

### A) Pyrex installation on Windows XP ###
# step A.1 #
Install Python (we used version 2.4.2)
# step A.2 #
Run the windows installer for Pyrex (e.g. Pyrex-0.9.3.1.win32.exe),
available on the Pyrex homepage
(http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/)
# step A.3 #
Install Mingw, the gcc compiler for Windows, available at
http://www.mingw.org/download.shtml. (we downloaded the file
MinGW-5.0.2.exe and installed only the "base tool" (this includes
mingw-runtime 3.9, w32api-3.6, binutils 2.15.91 and gcc-core 3.4.2).
Add Mingw path ("C:\MinGW\bin") to the Windows "Path" environment
variable. If you already have cygwin installed, add C:\MinGW\bin before
the Cygwin path.
# step A.4 #
Create or edit the file "c:/Python2x/Lib/distutils/distutils.cfg" and
put the following into it:
[build]
compiler = mingw32

-------------------------------------------
### B) Create a Pyrex module ###
# step B.1 #
Create a working directory (e.g. D:\pyrex_module\). Write a pyrex
module and save it with a "pyx" extension (e.g. "primes.pyx", code
available on the Pyrex homepage)
# step B.2 #
Write the following python script and save it as "setup.py" in your
working directory.

from distutils.core import setup
from distutils.extension import Extension
from Pyrex.Distutils import build_ext
setup(
name = "PyrexGuide",
ext_modules=[
Extension("primes", ["primes.pyx"])
],
cmdclass = {'build_ext': build_ext}
)

If you want to compile several modules, duplicate the line starting
with "Extension" and replace "primes" by your module names.
# step B.3 #
In your working directory, create a batch file called
"build_and_install.bat" containing the following lines, where
"PythonXX" should be replaces by your Python version (e.g. "Python24").

C:\Python24\python.exe setup.py build_ext install
pause

To run the batch, double-click the file. You will see many "Warning"
messages during the building process: do not worry, it is normal.
# step B.4 #
Mission completed. The file "primes.pyd" (a "pyd" is a Python Extension
DLL, equivalent of .so in Unix) is now located in
"C:\Python24\Lib\site-packages" and the "primes" module is available in
Python. In your working directory, you can delete the file "primes.c"
and the "build" folder created by the building process.

Test your new module at the python shell:

import primes
primes.primes(10)

[2, 3, 5, 7, 11, 13, 17, 19, 23, 29]

--------------------------------------------

[Michel Claveau]

Merci beaucoup !
Thank you very much!

--
@-salutations

Michel Claveau

[vj]

Can you use the stock python build or do you have to build python from
scratch with mingw to use pyrex modules built with mingw?

[Julien Fiore]

To install Pyton, I simply used the python Windows installer
(python-2.4.2.msi) available at python.org.

Julien

[Boris Borcic]

Julien Fiore wrote:

Do you wand to install Pyrex on Windows ?

Here is a step-by-step guide explaining:

A) how to install Pyrex on Windows XP.
B) how to compile a Pyrex module.

Julien Fiore,
U. of Geneva
Thanks. One detail missing : for this (step b3) to work smoothly, one needs to
make sure that (a copy of) eg python24.dll resides in Python24\libs\

-------------------------------------------

### A) Pyrex installation on Windows XP ###
# step A.1 #
Install Python (we used version 2.4.2)
# step A.2 #
Run the windows installer for Pyrex (e.g. Pyrex-0.9.3.1.win32.exe),
available on the Pyrex homepage
(http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/)
# step A.3 #
Install Mingw, the gcc compiler for Windows, available at
http://www.mingw.org/download.shtml. (we downloaded the file
MinGW-5.0.2.exe and installed only the "base tool" (this includes
mingw-runtime 3.9, w32api-3.6, binutils 2.15.91 and gcc-core 3.4.2).
Add Mingw path ("C:\MinGW\bin") to the Windows "Path" environment
variable. If you already have cygwin installed, add C:\MinGW\bin before
the Cygwin path.
# step A.4 #
Create or edit the file "c:/Python2x/Lib/distutils/distutils.cfg" and
put the following into it:
[build]
compiler = mingw32

-------------------------------------------
### B) Create a Pyrex module ###
# step B.1 #
Create a working directory (e.g. D:\pyrex_module\). Write a pyrex
module and save it with a "pyx" extension (e.g. "primes.pyx", code
available on the Pyrex homepage)
# step B.2 #
Write the following python script and save it as "setup.py" in your
working directory.

from distutils.core import setup
from distutils.extension import Extension
from Pyrex.Distutils import build_ext
setup(
name = "PyrexGuide",
ext_modules=[
Extension("primes", ["primes.pyx"])
],
cmdclass = {'build_ext': build_ext}
)

If you want to compile several modules, duplicate the line starting
with "Extension" and replace "primes" by your module names.
# step B.3 #
In your working directory, create a batch file called
"build_and_install.bat" containing the following lines, where
"PythonXX" should be replaces by your Python version (e.g. "Python24").

C:\Python24\python.exe setup.py build_ext install
pause

To run the batch, double-click the file. You will see many "Warning"
messages during the building process: do not worry, it is normal.
# step B.4 #
Mission completed. The file "primes.pyd" (a "pyd" is a Python Extension
DLL, equivalent of .so in Unix) is now located in
"C:\Python24\Lib\site-packages" and the "primes" module is available in
Python. In your working directory, you can delete the file "primes.c"
and the "build" folder created by the building process.

Test your new module at the python shell:

import primes
primes.primes(10)

[2, 3, 5, 7, 11, 13, 17, 19, 23, 29]

--------------------------------------------

[sturlamolden]

Julien Fiore wrote:

# step A.3 #
Install Mingw, the gcc compiler for Windows, available at
http://www.mingw.org/download.shtml. (we downloaded the file
MinGW-5.0.2.exe and installed only the "base tool" (this includes
mingw-runtime 3.9, w32api-3.6, binutils 2.15.91 and gcc-core 3.4.2).
Add Mingw path ("C:\MinGW\bin") to the Windows "Path" environment
variable. If you already have cygwin installed, add C:\MinGW\bin before
the Cygwin path.

I don't think this is safe. MinGW links with msvcrt.dll whereas the
main Python distribution links with msvcr71.dll (due to Visual C++
2003). It is not safe to mix and blend different C runtime libraries.
If you are to build a C extension with MinGW, you also need to build
Python against msvcrt.dll, i.e. you have to use a Python built with
MinGW or Visual C++ 6.0. There other option is to make MinGW link
against msvcr71.dll. I don't know if that is feasible.

[Julien Fiore]

Thanks for your remark, Sturlamolden.

Is there a free version of the "Visual C++ 2003" compiler available on
the web? I have found "Visual C++ 2005 Express edition"
(http://msdn.microsoft.com/vstudio/express/visualc/). According to
Micrsoft, it replaces VC++2003
(http://msdn.microsoft.com/visualc/vctoolkit2003/). Is VC++2005ee the
good compiler to compile a Pyrex module (or any Python extension) ?
Does it link with msvcr71.dll ?

[sturlamolden]

Julien Fiore wrote:

Thanks for your remark, Sturlamolden.

Is there a free version of the "Visual C++ 2003" compiler available on
the web? I have found "Visual C++ 2005 Express edition"
(http://msdn.microsoft.com/vstudio/express/visualc/). According to
Micrsoft, it replaces VC++2003
(http://msdn.microsoft.com/visualc/vctoolkit2003/). Is VC++2005ee the
good compiler to compile a Pyrex module (or any Python extension) ?
Does it link with msvcr71.dll ?

The bad news is that "Visual C++ 2005 Express" links with msvcr80.dll,
which incompatible with both msvcrt.dll and msvcr71.dll. What you need
is the "Microsoft .NET Framework SDK Version 1.1". It contains version
7.1 of Microsoft's C/C++ compiler and links with the correct CRT.

http://tinyurl.com/5flob

I am not sure if this is an optimizing compiler. Microsoft did not give
away their optimizing compiler prior to "Visual C++ 2005 Express". Even
the standard version of Visual Studio did not have an optimizing
compiler, it only shipped with the professional and enterprise
versions. If this compiler does not optimize, you may try to make
"Visual C++ 2005 Express" use the import library for msvcr71.dll which
ships with the .NET SDK.

Now you know the meaning of the word "DLL HELL".

[sturlamolden]

sturlamolden wrote:

I don't think this is safe. MinGW links with msvcrt.dll whereas the
main Python distribution links with msvcr71.dll (due to Visual C++
2003).

In order to make minGW link with msvcr71.dll, edit the text file

c:\mingw\lib\gcc\mingw32\3.2.4\specs

and change "-lmsvcrt" to "-lmsvcr71".

Now MinGW will link with the same CRT as Python 2.4.

[Julien Fiore]

sturlamolden wrote:

edit the text file "c:\mingw\lib\gcc\mingw32\3.2.4\specs"
and change "-lmsvcrt" to "-lmsvcr71".

Thank you very much sturlamolden,

This procedure should be added to the "step-by-step" guide (see 1st
message of this thread) as "step A.5".

For ignorant people like me, CRT = "C runtime library".

[Julien Fiore]

I added "step A.5" to the guide and published it on the Python wiki, so
that anyone can update it easily:
http://wiki.python.org/moin/PyrexOnWindows

[Jim Lewis]

> and change "-lmsvcrt" to "-lmsvcr71".

But then I get this error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with the same version of the
compiler, but it isn't installed.
I want to use mingw.

[Gonzalo Monzón]

sturlamolden escribió:

Julien Fiore wrote:

# step A.3 #
Install Mingw, the gcc compiler for Windows, available at
http://www.mingw.org/download.shtml. (we downloaded the file
MinGW-5.0.2.exe and installed only the "base tool" (this includes
mingw-runtime 3.9, w32api-3.6, binutils 2.15.91 and gcc-core 3.4.2).
Add Mingw path ("C:\MinGW\bin") to the Windows "Path" environment
variable. If you already have cygwin installed, add C:\MinGW\bin before
the Cygwin path.

I don't think this is safe. MinGW links with msvcrt.dll whereas the
main Python distribution links with msvcr71.dll (due to Visual C++
2003). It is not safe to mix and blend different C runtime libraries.
If you are to build a C extension with MinGW, you also need to build
Python against msvcrt.dll, i.e. you have to use a Python built with
MinGW or Visual C++ 6.0. There other option is to make MinGW link
against msvcr71.dll. I don't know if that is feasible.

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.

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?

Hope it helps,
Gonzalo.

[Robert Kern]

sturlamolden wrote:

sturlamolden wrote:

I don't think this is safe. MinGW links with msvcrt.dll whereas the
main Python distribution links with msvcr71.dll (due to Visual C++
2003).

In order to make minGW link with msvcr71.dll, edit the text file

c:\mingw\lib\gcc\mingw32\3.2.4\specs

and change "-lmsvcrt" to "-lmsvcr71".

Now MinGW will link with the same CRT as Python 2.4.

However, MinGW's header files are still written for MSVCRT.dll. IIRC, isupper()
and friends use a jump table called _ctype in MSVCRT.dll which is missing in
MSVCR71.dll. Some extensions will compile okay, some won't.

The order in which distutils adds 'msvcr71' to the list of libraries seems to
make sure that the PYD picks up free, malloc, printf, and other important
functions from MSVCR71.dll first before trying MSVCRT.dll. However, C++ modules
that use std::cout, for example, will crash.

AFAICT, there is currently no general solution for compiling Python 2.4
extension modules with MinGW. There probably won't be one unless MinGW is
patched to fully use MSVCR71.dll.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Robert Kern]

Jim Lewis wrote:

and change "-lmsvcrt" to "-lmsvcr71".

But then I get this error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with the same version of the
compiler, but it isn't installed.
I want to use mingw.

You have to tell distutils to use mingw:

python setup.py build_ext --compiler=mingw32

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Robert Kern]

Gonzalo Monzón wrote:

sturlamolden escribió:

I don't think this is safe. MinGW links with msvcrt.dll whereas the
main Python distribution links with msvcr71.dll (due to Visual C++
2003). It is not safe to mix and blend different C runtime libraries.
If you are to build a C extension with MinGW, you also need to build
Python against msvcrt.dll, i.e. you have to use a Python built with
MinGW or Visual C++ 6.0. There other option is to make MinGW link
against msvcr71.dll. I don't know if that is feasible.

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.

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?

Nope. He said it because it is true. Use Dependency Walker
(http://www.dependencywalker.com) to see for yourself what DLLs are linked in.
In fact, *both* DLLs are linked in. Sometimes this works fine, other times it
does not.

If you would like a more visceral demonstration, write a small C++ extension
that uses std::cout.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Gonzalo Monzón]

Robert Kern escribió:

Gonzalo Monzón wrote:

sturlamolden escribió:

I don't think this is safe. MinGW links with msvcrt.dll whereas the
main Python distribution links with msvcr71.dll (due to Visual C++
2003). It is not safe to mix and blend different C runtime libraries.
If you are to build a C extension with MinGW, you also need to build
Python against msvcrt.dll, i.e. you have to use a Python built with
MinGW or Visual C++ 6.0. There other option is to make MinGW link
against msvcr71.dll. I don't know if that is feasible.

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.

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?

Nope. He said it because it is true. Use Dependency Walker
(http://www.dependencywalker.com) to see for yourself what DLLs are linked in.
In fact, *both* DLLs are linked in. Sometimes this works fine, other times it
does not.

If you would like a more visceral demonstration, write a small C++ extension
that uses std::cout.

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

[Robert Kern]

Gonzalo Monzón wrote:

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?

If you use std::cout in a C++ extension module that was built with the stock
Python 2.4 distutils and the stock MinGW, you will crash the interpreter.
"Bundling the right CRT" is not the issue. *Building* with the right CRT is.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Jim Lewis]

Thanks. I had done that but it seems I had to remove "install". Now it
works.

[Gonzalo Monzón]

Robert Kern escribió:

Gonzalo Monzón wrote:

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?

If you use std::cout in a C++ extension module that was built with the stock
Python 2.4 distutils and the stock MinGW, you will crash the interpreter.
"Bundling the right CRT" is not the issue. *Building* with the right CRT is.

Ok, I left building out of the equation... I misunderstood the issue. Of
course, you need to build always using the same crt.

Regards,
Gonzalo

[Claudio Grondi]

sturlamolden wrote:

Julien Fiore wrote:

Thanks for your remark, Sturlamolden.

Is there a free version of the "Visual C++ 2003" compiler available on
the web? I have found "Visual C++ 2005 Express edition"
(http://msdn.microsoft.com/vstudio/express/visualc/). According to
Micrsoft, it replaces VC++2003
(http://msdn.microsoft.com/visualc/vctoolkit2003/). Is VC++2005ee the
good compiler to compile a Pyrex module (or any Python extension) ?
Does it link with msvcr71.dll ?

The bad news is that "Visual C++ 2005 Express" links with msvcr80.dll,
which incompatible with both msvcrt.dll and msvcr71.dll. What you need
is the "Microsoft .NET Framework SDK Version 1.1". It contains version
7.1 of Microsoft's C/C++ compiler and links with the correct CRT.

http://tinyurl.com/5flob

I am not sure if this is an optimizing compiler.

The free available Visual C++ 2003 compiler is the optimizing one.
You have to get it separately downloading the Visual C++ Toolkit 2003
which comes with the Professional version of Microsoft Visual C++ .NET
2003 compiler and linker.

Claudio
Microsoft did not give
away their optimizing compiler prior to "Visual C++ 2005 Express". Even
the standard version of Visual Studio did not have an optimizing
compiler, it only shipped with the professional and enterprise
versions. If this compiler does not optimize, you may try to make
"Visual C++ 2005 Express" use the import library for msvcr71.dll which
ships with the .NET SDK.

Now you know the meaning of the word "DLL HELL".

[Jim Lewis]

Still problems :-(

I have a directory c:\data\code\test\pyrex containing:

build_and_install.bat:
"C:\program files\Python\python.exe" setup.py build_ext
--compiler=mingw32
pause

setup.py:
from distutils.core import setup
from distutils.extension import Extension
from Pyrex.Distutils import build_ext
setup(
name = "PyrexGuide",
ext_modules=[
Extension("worldimport", ["world.pyx"])
],
cmdclass = {'build_ext': build_ext}
)

world.pyx - pyrex code

run.py:
import worldimport
....
========================
The batch file creates a build folder with subfolders containing:
world.pyd, world.def, world.o, worldimport.def

But running run.py gives: "ImportError: No module named worldimport"

Should worldimport.def be going to C:\program
files\python\Lib\site-packages?
Why isn't it?

[Robert Kern]

Jim Lewis wrote:

Still problems :-(

I have a directory c:\data\code\test\pyrex containing:

build_and_install.bat:
"C:\program files\Python\python.exe" setup.py build_ext
--compiler=mingw32
pause But running run.py gives: "ImportError: No module named worldimport"

Should worldimport.def be going to C:\program
files\python\Lib\site-packages?
Why isn't it?

You also have to run the distutils install command as well to place the results
of the build in site-packages.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Jim Lewis]

Thanks but now another problem :-(
Examples in books show importing a global so why does below give:
AttributeError: 'module' object has no attribute 'globalvar'

primes.pyx:
from run import globalvar
def prime(int kmax):
result = [run.globalvar]
....

run.py:
from primes import prime
globalvar = 999
while True:
print prime (10)

[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.

[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

[sturlamolden]

Gonzalo Monzón wrote:

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? ...
It does not matter which crt you "supply". The dynamic linker will
attempt to load the crt specified by the import library that you linked
when the extension was built. What will happen, is that Windows will
search through its "search path" (i.e. the current folder and folder
specified by the PATH environment variable) until it find the crt it
wants.

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- ?
Windows will e.g. look in its own directories as well. You can bundle
msvcr71.dll, but msvcrt.dll will always be available in
c:\windows\system32. If you used an import library for msvcrt.dll, then
msvcrt.dll will be loaded.

Also you cannot legally bundle msvcr71.dll unless you hold a license
for Visual Studio 2003. There are no other way to legally redistribute
msvcr71.dll. Other versions of Visual Studio allows redistribution of
other versions of the crt. Visual C++ Toolkit 2003 only allows a
statically linked crt.
Of course if you didn't bundle the right crt, it does depend on the
available crt on target system...

No it does not. It always depends on the CRT specified by the import
library. If you linked against msvcr71.lib, then the extension needs to
load msvcr71.dll. If Windows cannot find msvcr71.dll on the search
path, the process will be killed. It is your responsibility to make
sure msvcr71.lib reside on the search path. If it cannot be found,
Windows will not load a different crt instead. Windows will pop up a
warning message telling you that msvcr71.dll cannot be found, and then
kill the process.

If you linked against msvcrt.lib, then the extension will load
msvcrt.dll.

[greg]

Jim Lewis wrote:

Thanks but now another problem :-(
Examples in books show importing a global so why does below give:
AttributeError: 'module' object has no attribute 'globalvar'

primes.pyx:
from run import globalvar
def prime(int kmax):
result = [run.globalvar]
...

run.py:
from primes import prime
globalvar = 999
while True:
print prime (10)

The first thing run does is import primes, which
immediately imports run and tries to access the
name globalvar in it, before it has been defined.

There are ways of fixing that, but for various
reasons it's usually a bad idea for subsidiary
modules to try to import things from the main
module of a program. It would be better to move
globalvar into a third module.

Even better again would probably be not to use
a global at all, but pass it in as a parameter
to the prime() function.

--
Greg