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

[Luke Kenneth Casson Leighton]

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<module>) 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.