Linux for Windows 上的交叉编译扩展

Question

我已经成功地在 Linux 上构建了一些使用 MinGW 进行 Python 扩展所必需的 DLL。沿着这些思路：

from setuptools.command.build_py import build_py

class BuildGo(build_py):

    def run(self):
        if # need to build windows binaries
            self.build_win()
        build_py.run(self)

    def build_win(self):
        if # compilers and toolchain available
            try:
                # builds extra libraries necessary for this extension
            except subprocess.CalledProcessError as e:
                print(e.stderr)
                raise
            try:
                result = subprocess.check_output([
                    'x86_64-w64-mingw32-gcc-win32',
                    '-shared',
                    '-pthread',
                    '-o',
                    EXTRA_DLL,
                    FAKE_WIN_BINDINGS,
                    ARCHIVE_GENERATED_IN_PREVIOUS_STEP,
                    '-lwinmm',
                    '-lntdll',
                    '-lws2_32',
                ])
                print(result)
            except subprocess.CalledProcessError as e:
                print(e.stderr)
                raise

我现在希望我可以避免build_ext以同样痛苦的方式进行扩展，让它为 Windows 交叉编译 Cython 代码...我研究了“和”setuptools的优雅相互作用的深渊，在深渊有机会看到之前回到我身上...是否有一种方法可以只指定一些标志...例如所需平台的编译器名称和Python二进制文件...它就可以做到这一点？distutilscython

我读过这篇文章：http://whatschrisdoing.com/blog/2009/10/16/cross-compiling-python-extensions/ - 它已经快 10 岁了。这让我想哭……自从写下来之后有什么改变吗？或者这些步骤或多或少是我必须为除我正在运行的平台之外的平台进行编译的步骤？

或者，网络上是否有一个示例项目可以做到这一点？

目标

我的最终目标是生成一个egg包，其中包含 PE 和 ELF 二进制文件，并在由pip或安装时将它们安装在任一平台上的正确位置pipenv。它应该可以在 Linux 上编译（不需要在 MS Windows 上编译）。

Answer 1

我将其发布为社区维基，因为这是一个非常令人不满意的答案：它只告诉您为什么它非常困难，而不是提供真正的解决方案。

Windows 上的官方 Python 发行版是使用 Microsoft Visual C (MSVC) 编译的，在编译 Python 扩展时，通常需要使用与编译 Python 相同的版本。这表明精确的编译器匹配非常重要。

可以获得使用 Mingw 编译的 Python 版本，然后这些版本将与使用 Mingw 编译的模块兼容。这可能可以作为 Linux 上的交叉编译器工作，但这些模块仅对拥有此自定义 Python 版本的一小部分人有用（因此无助于创建有用的可分发 .egg 文件）。

我们还付出了合理的努力来制作一个可以在 Windows 上构建兼容的 Python 扩展的 Mingw 版本： https: //mingwpy.github.io/（我认为也https://anaconda.org/msys2/m2w64-toolchain） 。造成这种情况的主要驱动因素似乎是缺乏与 MSVC 兼容的 Windows 免费 Fortran 编译器，因此构建 Fortran 模块的能力非常有用。根据我的经验，mingwpy 工具链运行得非常好，直到 Python 3.4，当切换到更新版本的 MSVC 时，带来了一系列令人兴奋的新兼容性问题。

我的感觉是，任何可行的解决方案都可能基于这些主要用于 Windows 的 Mingw 编译器。