[Distutils] Mingw Python 2.4

[AGiss]

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