[Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now (original) (raw)

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Jan 23 07:36:02 CET 2009

On Thu, Jan 22, 2009 at 9:09 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

mrmmm... how? apps won't end up loading both libpython2.5.dll and python25.dll (or libpython2.N.dll and python2N.dll) will they? Of course they will!

yeah, silly - i worked that out juust after i pressed "send".

python.exe (say, the official one) loads python25.dll. Then, an import is made of a ming-wine extension, say foo.pyd, which is linked with libpython2.5.dll, which then gets loaded. Voila, you have two interpreters in memory, with different type objects, memory heaps, and so on.

ok, there's a solution for that - the gist of the solution is already implemented in things like Apache Runtime and Apache2 (modules), and is an extremely common standard technique implemented in OS kernels. the "old school" name for it is "vector tables".

so you never let the .pyd (or so even) modules "link" to the libpythonN.N.dll, pythonNN.dll (or libpythonN.N.so even), you pass in a pointer to everything it's ever going to need (in its init) function.

This was always the problem when an old extension module (say, from 2.4) was loaded into a new interpreter (say, 2.5), then you load both python25.dll and python24.dll, causing crashes. To prevent this issue, Python now checks whether the module is linked with an incorrect pythonxy.dll, but won't catch that libpython2.5.dll is also a VM.

ok.

i'll look at making libpython2.5.dll equal to python25.dll.

(of course, msvcr80 is irrelevant, because Python had never been using that officially)

oh? i saw the PCbuild8 and thought it was. oh that's even better - if python2.5 only officially support msvcrt whew. No, Python 2.5 is linked with msvcr71.dll.

ehn? i don't see that anywhere in any PC/* files - i do see that there's a dependency on .NET SDK 1.1 which uses msvcr71.dll

still, 71 is good news - as long as it's not involving assemblies.

2.6 is a different matter, but, thinking about it, i have hopes that the better-tested-codepath of the 2.6 codebase would have better luck with 9.0 [than i had with 2.5 and 8.0] simply because... it's been tested already! [and 2.5 with 8.0 hadn't]

l.

More information about the Python-Dev mailing list