Python 2.6 and wrapping C libraries on Windows

[L. Lindstrom]

L. Lindstrom wrote:
> Christian Heimes wrote:
>> L. Lindstrom schrieb:
[snip]
>>> [B]esides heap management and FILE pointers, is there any reason SDL, or
>>> any C dependency, needs to link to the same C run-time as Python? If I
>>> ensure SDL frees memory it allocates and does not directly access a file
>>> opened by Python can I just use another C run-time such as msvcrt?
>>>
>>
>> Your analysis of the problem and the implication of mixing CRTs is
>> correct. However ...
>>
>> It should be trivial to modify the build systemof SDL so that the
>> manifest is integrated into the DLLs. Everything else is a hack. It
>> *should* work and in reality it *does* work for most cases. But someday
>> you'll hit a solid wall and get strange and hard to debug segfaults.
>>
[snip]
> Linking to msvcr90.dll is possible with MinGW. The problem is with the 
> configure scripts. So I can run configure against msvcrt.dll, then 
> switch to mscvr90.dll for make. If this works I will make SDL and a test 
> program available on-line so someone can find the appropriate manifests.
> 
> 
Here is my attempt to link SDL and a test program with msvcr90.dll. It 
can be found at http://www3.telus.net/len_l/pygame . The md5sum is:

f5b71d9934d35c35a24b668ad8023146 *VC-2008-Run-Time-test.zip

Both lack a manifest. The test program and SDL work when a surrogate 
run-time is provided, a renamed msvcr71.dll . So if someone can show me 
the necessary manifest to make SDL use the C run-time installed by the 
Python 2.6 installer I would appreciate it. SDL is built with MinGW so I 
doubt I can distribute the run-time with it.

-- 
Lenard Lindstrom
"%s@%s.%s" % ('len-l', 'telus', 'net')