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
"[EMAIL PROTECTED]" % ('len-l', 'telus', 'net')
--
http://mail.python.org/mailman/listinfo/python-list
