Python 2.6并在Windows上包装C库 [英] Python 2.6 and wrapping C libraries on Windows
问题描述
我已经读过，Python扩展模块必须链接到与Python解释器相同的C
运行时。这我可以欣赏。但是这个
要求是否扩展到扩展模块包装的C库。
的例子是Pygame和SDL。 Pygame扩展模块使用distutils构建
，因此对于使用Visual Studio 2008的Python 2.6，应确保.pyd文件链接到msvcr90.dll。
。但是SDL是使用Msys / MinGW
和configure / make工具链构建的。链接到
msvcr90.dll时失败，因为小测试程序配置版本缺少清单
文件。他们无法加载msvcr90.dll，而是引发了R6034错误。那么除了堆管理和FILE指针之外，有没有什么理由SDL或者任何C依赖关系需要链接到与Python相同的C运行时？如果我
确保SDL释放它分配的内存并且不直接访问文件由Python打开的
我可以使用另一个C运行时如msvcrt吗？
-
Lenard Lindstrom
" %s@%s.%s" ％（''len-l''，''telus''，''net''）
I have read that Python extension modules must link to the same C
run-time as the Python interpreter. This I can appreciate. But does this
requirement extend to the C libraries an extension module wraps. The
case in point is Pygame and SDL. The Pygame extension modules are built
with distutils, so for Python 2.6 using Visual Studio 2008 should ensure
the .pyd files link to msvcr90.dll. But SDL is built using Msys/MinGW
and the configure/make tool chain. This fails when linking to
msvcr90.dll since the small test programs configure builds lack manifest
files. They fail to load msvcr90.dll, raising an R6034 error instead. So
besides 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?
--
Lenard Lindstrom
"%s@%s.%s" % (''len-l'', ''telus'', ''net'')
推荐答案
L. Lindstrom schrieb：
L. Lindstrom schrieb:
我已经读过Python扩展模块必须链接到与Python解释器相同的C />
运行时。这我可以欣赏。但是这个
要求是否扩展到扩展模块包装的C库。
的例子是Pygame和SDL。 Pygame扩展模块使用distutils构建
，因此对于使用Visual Studio 2008的Python 2.6，应确保.pyd文件链接到msvcr90.dll。
。但是SDL是使用Msys / MinGW
和configure / make工具链构建的。链接到
msvcr90.dll时失败，因为小测试程序配置版本缺少清单
文件。他们无法加载msvcr90.dll，而是引发了R6034错误。那么除了堆管理和FILE指针之外，有没有什么理由SDL或者任何C依赖关系需要链接到与Python相同的C运行时？如果我
确保SDL释放它分配的内存并且不直接访问文件由Python打开的
我可以使用另一个C运行时如msvcrt吗？
I have read that Python extension modules must link to the same C
run-time as the Python interpreter. This I can appreciate. But does this
requirement extend to the C libraries an extension module wraps. The
case in point is Pygame and SDL. The Pygame extension modules are built
with distutils, so for Python 2.6 using Visual Studio 2008 should ensure
the .pyd files link to msvcr90.dll. But SDL is built using Msys/MinGW
and the configure/make tool chain. This fails when linking to
msvcr90.dll since the small test programs configure builds lack manifest
files. They fail to load msvcr90.dll, raising an R6034 error instead. So
besides 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?
您对问题的分析以及混合CRT的含义是正确的。但是......
修改SDL的构建系统以便将
清单集成到DLL中应该是微不足道的。其他一切都是黑客。它是* b $ b *应该*工作，实际上它* *适用于大多数情况。但总有一天
你会碰到一个坚固的墙，变得奇怪而且很难调试段错误。
得到它符合你自己的利益就在第一位。并且你会通过提供一个很好的教程如何
修改第三方构建来大大地为Python社区服务。 *提示* :)
如果您需要任何帮助，请随时与我联系。在Martin，Amaury和其他核心开发人员的帮助下，新的构建系统主要是我的工作。
Christian
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.
It''s in your own interest to get it right in the first place. And you''d
serve the Python community greatly by providing a nice tutorial how to
modify 3rd party builds. *hint* :)
If you need any help feel free to contact me. The new build system is
mostly my work with help from Martin, Amaury and other core developers.
Christian
4月30日晚上8:06，L。 Lindstrom的" < spam-t ... @ telus.netwrote：
On Apr 30, 8:06 pm, "L. Lindstrom" <spam-t...@telus.netwrote:
我读过Python扩展模块必须链接到同一个C
运行时作为Python解释器。这我可以欣赏。但是这个
要求是否扩展到扩展模块包装的C库。
I have read that Python extension modules must link to the same C
run-time as the Python interpreter. This I can appreciate. But does this
requirement extend to the C libraries an extension module wraps.
这有点误解。您无法在不同的CRT中可靠地混合和混合
CRT资源。这不是一个真正的Python
问题。它适用于任何程序。这对于
Python C扩展很重要，主要是访问Python
文件对象作为指向C中FILE结构的指针的可能性。如果你得到一个FILE *
来自一个CRT的指针，你不应该将它传递给另一个CRT的fread。
同样，如果你用一个CRT的malloc分配内存（ ），你应该
不要用另一个CRT'的free（）释放内存。只要你的
图书馆不共享CRT资源，对于他们的内部工作而言，链接
到不同的CRT并不重要。
This somewhat of a misconception. You cannot reliably mix and blend
CRT resources across different CRTs. This is not really a Python
problem. It applies to any program. The reason this is important for
Python C extensions, is mainly the possibility of accessing a Python
file object as a pointer to a FILE struct in C. If you get a FILE*
pointer from one CRT, you should not pass it to another CRT''s fread.
Likewise, if you allocate memory with one CRT''s malloc(), you should
not release the memory with another CRT''s free(). As long as your
libraries don''t share CRT resources, it does not matter that the link
to different CRTs for their internal work.
Christian Heimes写道：
Christian Heimes wrote:
L. Lindstrom schrieb：
L. Lindstrom schrieb:
>我已经读过Python扩展模块必须链接到与Python解释器相同的C />运行时。这我可以欣赏。但是这个
要求是否扩展到扩展模块包装的C库。
的例子是Pygame和SDL。 Pygame扩展模块使用distutils构建，因此对于使用Visual Studio 2008的Python 2.6，应确保.pyd文件链接到msvcr90.dll。但是SDL是使用Msys / MinGW
和configure / make工具链构建的。链接到msvcr90.dll时失败，因为小测试程序配置版本缺少清单文件。他们无法加载msvcr90.dll，而是引发了R6034错误。那么除了堆管理和FILE指针之外，SDL或任何C依赖关系是否需要链接到与Python相同的C运行时？如果我确保SDL释放内存它分配并且不直接访问由Python打开的文件我可以使用另一个C运行时如msvcrt吗？
>I have read that Python extension modules must link to the same C
run-time as the Python interpreter. This I can appreciate. But does this
requirement extend to the C libraries an extension module wraps. The
case in point is Pygame and SDL. The Pygame extension modules are built
with distutils, so for Python 2.6 using Visual Studio 2008 should ensure
the .pyd files link to msvcr90.dll. But SDL is built using Msys/MinGW
and the configure/make tool chain. This fails when linking to
msvcr90.dll since the small test programs configure builds lack manifest
files. They fail to load msvcr90.dll, raising an R6034 error instead. So
besides 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?
您对问题的分析以及混合CRT的含义是正确的。但是......
修改SDL的构建系统以便将
清单集成到DLL中应该是微不足道的。其他一切都是黑客。它是* b $ b *应该*工作，实际上它* *适用于大多数情况。但总有一天
你会碰到一个坚固的墙，变得奇怪而且很难调试段错误。
得到它符合你自己的利益就在第一位。并且你会通过提供一个很好的教程如何
修改第三方构建来大大地为Python社区服务。 *提示* :)
如果您需要任何帮助，请随时与我联系。在Martin，Amaury和其他核心开发人员的帮助下，新的构建系统主要是我的工作。
Christian
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.
It''s in your own interest to get it right in the first place. And you''d
serve the Python community greatly by providing a nice tutorial how to
modify 3rd party builds. *hint* :)
If you need any help feel free to contact me. The new build system is
mostly my work with help from Martin, Amaury and other core developers.
Christian
MinGW可以链接到msvcr90.dll。问题在于
配置脚本。所以我可以针对msvcrt.dll运行configure，然后
切换到mscvr90.dll for make。如果这样可行，我将在线提供SDL和测试
计划，以便有人找到合适的清单。
-
Lenard Lindstrom
" %s@%s.%s" ％（''len-l''，''telus''，''net''）
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.
--
Lenard Lindstrom
"%s@%s.%s" % (''len-l'', ''telus'', ''net'')
这篇关于Python 2.6并在Windows上包装C库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
