On Sun, Apr 03, 2005 at 06:08:34PM +0900, Michiel Jan Laurens de Hoon wrote:
I just tried to compile a bunch of C extensions (coming from the biopython project) with mingw as compiler. Most of them link to msvcr71.dll and not to msvcrt.dll, except for one, which links to both. By uncommenting various parts of the code, I discovered that the culprit is a call to strdup. When such a call is made, the extension module will link to both msvcr71.dll and msvcrt.dll. Now, strdup is not part of ANSI-C, so for portability it is better to avoid this function altogether. I don't know if your extension module links to msvcrt.dll for the same reason, but you may be able to find out which part of the code is causing the .pyd to be linked to msvcrt. It may turn out to be strdup or another non-standard function.
--Michiel.
The extension is "clearsilver" (http://www.clearsilver.net/). It's a "third-party" extension, so "not using" strdup is not a "clean" solution. (while in this case, rewritting it is quite simple, so it didn't took me much time to do it). So the .pyd generated with distutils linked to msvcrt.dll and to msvcr71.dll calls linked to msvcrt.dll : _close _fdopen _mkdir _mktemp _open _putenv _read _rmdir _sleep _stat _strdup _tzset _unlink _write _findclose _findfirst _findnext _fullpath calls linked to msvcr71.dll : __dllonexit __mb_cur_max _errno _iob _isctype _pctype _stricmp _strnicmp _vsnprintf abort atoi bsearch calloc fclose fflush fgets fopen fprintf fread free fseek fwrite getenv gmtime localtime malloc memchr memcpy memmove memset mktime qsort rand realloc rename sprintf srand sscanf strcat strchr strcmp strcpy strerror strftime strlen strncat strncmp strncpy strpbrk strrchr strspn strstr strtol time tolower toupper vfprintf vprintf vsprintf while all calls in the first section ARE exported in msvcr71.dll too (so that's not a problem of "msvcr71.dll" doesn't have them) (I suppose that msvcr71.dll export ALL the items mscvrt.dll plus some more). And so yes, _stdup is in the list. I tried to remove the strdup calls (just in case strdup would be the *only* "trigger" to that weirdness). So I replace all calls to strdup to strxdup, and I wrote a quick strxdup using just "strlen", "malloc" and "strncpy". The result was ... _strdup wasn't in the list of dependences from neo_cgi.pyd to msvcrt.dll. But all others were still remaining. And so in the list, if unlink, sleep or fdopen aren't ANSI-C, they look like POSIX to me. So I feel like using them. Am I wrong ? So I don't know what is really happening (look like MingW32 has problems handling msvcr71.dll, but I'm far from being competent to say that), but I feel like distutils should do something to not generate .pyd that would crash python scripts. (perhaps generate .pyd with mscvr71, then look if .pyd is linked to several run-time libs, and if yes, "downgrade" to mscvrt ?) --AGiss