Python in sci/tech applications
no-spam at no-spam-no-spam.invalid
Fri Nov 3 18:30:12 CET 2006
Robert Kern wrote:
> Magnus Lycka wrote:
>> robert wrote:
>>> When one follows ..
>>> ..this seems only to cover the immediate python dll issues. What
>>> happens with the C runtime libraries? You'll bind 2 different C-RTLs
>>> (DLLs) etc.? And what happens for example with heap objects created
>>> with one C-RTL and deleted/free'd with the other?
>> As far as I understand, there should be only one runtime library
>> involved. MinGW relies on the Microsoft runtime. It seems some
>> people have had problems using MSVCRT71 with MinGW, but I'm sure
>> that e.g. the Enthought people can explain those issues, since they
>> bundle MinGW in their Python 2.4 distribution.
> No, there are two if you use an unmodified Mingw distribution. Mingw is
> built around MSVCRT.dll . For many extensions, this doesn't cause a
> problem since things like FILE pointer don't cross C runtime boundaries.
> One can edit gcc's spec file to make it use MSVCR71.dll . However,
> Mingw's headers are still written for MSVCRT.dll and Microsoft changed
> some of the internal details that they rely upon. For many (most?)
> extensions, this won't matter, either. C++ extensions using iostreams
> have a problem, IIRC. Unfortunately, neither approach works for all
> extensions. It may even be the case that some extensions won't work
> under *either* method.
In past I asked for linking Python2.5 and next Pythons on Win against such standard DLL (MSVCRT4 or MSVCRT.DLL)- yet Martin v. Löwis somehow explained in
somehow that MSVCRT.dll is not intended for normal apps - only for "system-level components".
Now I'm stun that MingW by default works with that library by default!
Another reason for my former request (in addition to ease of use with other compilers) was, that you don't have to package the big CRT7/8.. libs with frozen apps.
More information about the Python-list