[Distutils] Mingw Python 2.4
public-dstml at giss.ath.cx
Sun Apr 3 13:32:34 CEST 2005
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.
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
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
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
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
More information about the Distutils-SIG