Problem with msvcrt60 vs. msvcr71 vs. strdup/free

Gerhard Haering gh at ghaering.de
Tue Dec 21 08:48:06 EST 2004


Hello,

I used to build Python extension modules with mingw. Now, Python has
switched to the MSVCR71 runtime with version 2.4, and I thought mingw
has support for this. But I get problems with symbols being referenced
from the wrong DLLs.

You can see the problem by compiling this:

##################
#include <string.h>

int main()
{
    char* s;
    int i;


    for (i = 0; i < 10; i++) {
        s = strdup("foo");
        free(s);
    }

    return 0;
}
##################

with gcc x.c -lmsvcr71

Then if you run a.exe it crashes.

If you use depends.exe on it, you see that it resolves strdup() via
msvcrt, but the rest with msvcr71.dll. That's why strdup() is using
the one malloc, but free() a different free() from the other DLL,
which is undoubtedly the reason for the crash.

Is there any way I can force mingw to not link in msvcr for things
like strdup?

I think I found a very strange and ugly workaround: if I use _strdup()
instead of strdup(), it is resolved using the msvcr71 DLL.

I hope it is (soon) possible to use only the msvcr71 runtime from the
mingw compiler.

-- Gerhard
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20041221/1ff0e4d9/attachment.sig>


More information about the Python-list mailing list