On 23/01/2007 9.14, V. Armando Sole wrote:
With that patch installed, the whole PyQt+Qt block should use *only*
msvcr71.dll (you can verify it by inspecting the dependencies of the
generated dynamic libraries). If that's the case, it surely means that
this is *not* the problem causing a random crash.
If I run depends on almost any library I find dependences on msvcrt.dll
thru other libraries. For instance, for QtCore4.dll I get dependences on
msvcrt.dll thru ADVAPI32.DLL and WS2_32.DLL
That does not matter of course. Otherwise, you should recompile Windows to be
able to use VS2003 on your project, and I heard that's pretty hard to do :)
What you want to check is whether your Python extensions *directly* depend on
MSVCRT.DLL, instead of MSVCRT71.DLL.
The problem is that MS got it wrong with the CRT runtime. They underestimated
the fact that not every library is COM or export a pure Win32-only interface
to users :)
In Python, you mostly *can* mixmatch different CRT versions between the Python
core and the extensions. In fact, Python APIs are mostly CRT-agnostic, but
there are of course a few exceptions (like PyFile_FromFile which gets a
FILE*). If the extensions you write/use only limit themselves to the
CRT-agnostic part of the Python API, they will work fine even with a different
CRT version.
Remember also that *ALL* object allocation (both the PyObject_New and the
PyMem_New families) are totally CRT-agnostic, because they all happen within
the python.dll, so they all pull memory from the same heap; an extension which
follows the official Python API never manually allocates or frees Python
objects, but always do that with the proper APIs.
To the best of my understanding, current versions of PyQt/SIP *do* limit
themselves to the CRT-agnostic part of the Python API. I believe this was not
a design choice, but as I said we're speaking of a very large subset of the
APIs, so it's actually easy to get this right by chance. Instead, it is
*crucial* that PyQt and Qt are compiled with the *SAME* compiler, since Qt's
API are absolutely *NOT* CRT-agnostic: it's very common that an application
allocates an object (through "new") and the Qt code destroys it (eg: all
QWidgets children). So, basically, you can use whatever compiler you want for
PyQt and Qt, but it has to be the same for both!
[Of course, it would be nice if Python was totally and officially CRT
agnostic, so that users will have freedom to use whatever compiler they please
for extensions. Python 3k is a step forward in this direction, since the
planned rewriting of the I/O stack will not make use of the C file API
(fopen() and friends) but directly use platform APIs (POSIX open(), or Win32
CreateFile()).]
--
Giovanni Bajo
_______________________________________________
PyKDE mailing list [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
