On Mon, 13 Dec 2004 23:17:51 +0100, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > I forgot the details of your analysis, but I think you are right. > However, I would feel more comfortable if only a single CRT was used > from an extension module.
Agreed. But to some extent I'm equally uncomfortable with the idea that the mingw developers added support for -lmsvcr71 and botched it badly enough for things like this not to work :-) > As for creating a case that crashes if you mix CRTs: Just try > PyRun_SimpleFile in the extension, with a file that you fopen'ed > in the extension. Satisfy this fopen from, say, msvcrt.dll, and > load the extension into Python 2.4. Sorry, I wasn't specific enough. Certainly, if you create a FILE* from one CRT, then pass it to another CRT, this will fail. But my point is, if your extension uses fopen() then the link command generated by distutils will ensure that the symbol is satisfied from msvcr71.dll. So your scenario cannot occur. The only symbols which can be satisfied from msvcrt in a mingw-compiled extension (assuming that distutils is used, or the -lmsvcr71 flag is otherwise added) are those referenced in the mingw startup code, but not in user code. As the startup code will never reference Python APIs, CRT data should never be shared between incompatible CRTs. Your point about atexit (from another email) may be an issue. However, again we have the fact that user C code is *always* satisfied from msvcr71, so any exit handlers added in C or Python will be registered with the msvcr71 CRT, and so, as the main python.exe uses msvcr71, will be executed. I don't see any signs that the mingw runtime for a DLL uses atexit (this by experiment, I haven't time at the moment to review the mingw sources) and so I don't believe that the startup code has issues here, either. Thanks for your comments. Your support for the viability of building extensions using mingw is important to me, so if you still have any concerns, let me know and I will do my best to address them. Paul. _______________________________________________ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
