如何在Windows上构建MinGW x64

1 回答

• 10

  我想如果你必须有一个最小的Gnu-Windows 64位Gnu编译器集合，你应该检查MinGWTDM64 . 如果你担心MinGW32不适合你的目的，你可能会被误导（虽然我不能确定你想做什么或者是否可能） . 但是我发现TDM（Dragon？）在保持最新状态方面做得比在mingw组织本身做得更好（至少在最近） .

  如果你不能按照上面的说法，在我看来它更适合你，因为上面的内容非常反映了* nices的FSSTND（文件系统层次结构）标准 . 配置工具是GNU构建系统（q.v.尝试维基百科）的一部分，因此理解它需要知道它希望在预定路径上找到哪些源文件以及在何处编写其目标文件 . 这将指导您在环境（或平台，机器，操作系统等）中编译正确的头文件，以便生成可以正确运行的产品（编译器） .

  因为Gnu的非Unix（GNU）和Windows当然不是，因此从单个工具集生成一个可以处理任何一个的编译器是复杂的（读取“易碎”） . 构建编译器也不是开发人员职业生涯的第一步 . 因此，除非你准备好在血迹斑斑的小道上进行无尽的心碎（如果我可能会被允许一点点相似），请在我建议购买现成包装时再次幽默我 .

  我劝你了吗？不，好吧，不要试试 . 构建工具对编译的重要性在于 configure 本身是由它们构造的 . 通常有一组安装说明（一个GNU要求），比如"to build this package (let's say " Hello，World“将它保存在一个相当安全的阵营中”你必须先运行

  $> ./configure

  其次是

  $> make
  

  这本身就是一个粗略的过度简化，因为要么可以采用各种参数来确定您打算使用的编译器的类型和位置以及您打算安装产品的位置 . 但是，让我们不要分歧太多 . 这些说明将继续在许多这些软件包中说，“ configure 是使用autotools集构建的，但是你不必重新构建它来编译这个版本的helloworld . ”

  恕我直言，“ SHOULD NOT ”总是应该尽可能地大写，斜体，粗体强调和重复 . 通常情况下，重建配置的唯一时间是您拥有与作者相同的平台（架构，处理器，操作系统和环境） . 如果你很幸运并且作者是彻底的，那么即使作者最初在linux机器上构建它，你偶尔会在windows机器上对helloworld进行干净的编译 .

  我建议不要 Build GCC（mingw32,64或其他任何风味）的一个重要原因是我不建议你尝试了解autotools而没有生成自己的GNU发行版（即使只是为了练习） . 好吧，你问，“如果我还没有编译器，我该怎么做呢？”我能理解你的挫折感，甚至可以分享它 .

  如果您仍然希望自己将这个编译器套件放在Windows机器上（不使用MinGWTDM等），那么首先应该让它在Linux环境中运行 . 一旦你看到一个构建在那里工作，它会变得更清晰 . 我仍然没有看到任何可能产生完整编译器集（甚至是C编译器）的干净编译 . Harvard的David Malan使用虚拟环境远程教授CS50，这些环境非常像实际安装 . 它是免费的，他甚至在这个过程中教C，这将使您了解编译器选项（对于在不同环境中构建至关重要） .

  如果您不想运行虚拟化，或者您没有获得构建虚拟机的说明（不仅仅是构建编译器，不管信不信由你），您可以在某处安装某些品牌的Linux . 我建议不要在Windows机器上进行双重启动，因为它可能比构建编译器或虚拟机更具破坏性 .

  这样做并从Sourceforge下载一些Linux源代码包（强烈推荐的东西 - 你不需要错误的配置或构建脚本） . 按照说明操作 . 在Linux上构建它们然后在Windows上重复这个过程（你可以用32位编译器来完成它，除非有人告诉你你不能[99.9％的时间]） .

  转到其中一个 autotools/autoconf 教程（不是手册页，稍后再详细说明练习的含义） . 把你自己的helloworld包放在一起，生成你自己的 configure ，这样你就可以了 . 首先在Linux下进行，以确保更大的成功机会 - 然后'port'到Windows . 明智的一句话 - 避免任何有信号的东西 - 他们甚至不确定我如何做到这一点的想法甚至会起作用 .

  说了这么多之后，我会说一些更令人烦恼的事情：虽然mingw-w64-howto-build.txt编写得并不是特别好，但它并不像新手那样糟糕 . 事实上，我会说这是除了新手之外的任何东西 . 由于从源代码构建编译器（特别是在其原始主页之外）的过程并不是一件小事，如果您能找到任何能够在不使用相同词汇的情况下向您解释它的人，我会感到惊讶 . 做这种事的人以完全相同的方式互相交谈 . 除了涉及代码和构建脚本之外，它们的编写工作通常比上面的工作差得多 .

  但是要解决你的第一个问题，如果你没有选择更可实现的方法，那么 @prefix@ 或者在脚本中首先调用的是一种"home tree"（a）用于构建源，（b）用于构建目标和（c）用于构建安装 . Unix基于MULTICS，它提醒人们比尔盖茨在微软之前的工作是在XENIX上工作，三者都是"multi-user operating"或"processor control systems."多用户包含多个帐户，多个角色和多个构建/安装树的概念 .

  为自己构建编译器 - 特别是在构建的最后一部分是安装过程的情况下 - 与为同一台机器的其他用户构建它不同 . 让我们进一步扩展这个概念：让我们说你不是为自己和你的朋友做的 - 你是为你的公司做的，或者更有可能，“你的装置 . ”在这种情况下，您的安装将类似于您部署的基础：您不仅需要担心为您和在您的计算机上拥有帐户的朋友构建编译器 - 您必须担心为您的老板构建它，您的操作员，管理员，程序员，设计师以及任何可能需要/需要编译器来完成工作的人 . 您可能有几种类型的编译器必须共存，而您用于实验，开发， 生产环境 和测试的编译器可能是不同的版本和/或版本 .

  构建和安装树将有许多共同点 . PREFIX 试图解决这个问题 . 当我为自己的小沙箱构建时，我使用了我设置的前缀 ~/local . 这是* nices的特殊位置 . 〜是Windows术语中$ HOME或％home％的快捷方式 . 这是练习构建的最佳位置 . 它应该不需要特殊权限，但对那里的生活可能存在一些限制 . PREFIX 不会't solve all the problems but it gives the configuration tools an idea of where you'重新生成构建树和安装的树 . 在David Malan 's terms, if I' m将在 /home/jharvard/local/<product name>/src 中构建代码（并且某些版本的某些工具将坚持完整路径而不是通常的快捷方式 ~/<product name>/src ），我的 PREFIX 用于沙箱编译将是 ~/local 或 /home/jharvard/local 并且给出了合理的文件系统标准命名约定，您的可执行文件（生成的和/或现有的）将在 ~/local/bin 中，您的库将在 ~/local/lib 中，并且您的包含 Headers 将在 ~/local/include 中，而您正在玩这个自己的账户 . 这些东西是如何进入这些目录的？你在那里建造了它 . 并且您可能从诸如mingw-w64-howto-build.txt文件中引用的来源那样借用了诸如 Headers 之类的内容 .

  一些能够存活一段时间的工具可以升级到更广泛的用户群：他们会进入 /usr/local/src /usr/local/bin /usr/local/lib /usr/local/include . . . 等见 PREFIX ？一个问题是，要向那里推广，您必须是具有该路径的写权限的开发人员 - 否则您的配置将失败（除其他外） .

  有些工具具有它们根本不是本地的安装范围：那些可能从 /usr/src to /usr/bin using /usr/lib and /usr/include 编译 - 那是另一个 PREFIX .

  在只有神编译的系统根目录下，工具进入/ bin本身，如果不是/ sbin - 这些子树可以在不同目的的不同树上遍布整个系统 - like /usr/local/experimental/src, /usr/bullpen/development/etc, /usr/production/bin .

  我认为为什么人们选择不回答这样的帖子变得很清楚，但是这个练习可能因为各种各样的原因对很多人有用 .

  至于 default 是什么，当你没有't used something else. Actually, he'告诉你什么是默认值时，'s the default -- you know you'重新使用默认值，因为他告诉你“如果使用configure default /usr/local ”，那么配置默认 PREFIX 是 /usr/local . 如果您不使用任何其他内容，则表示您键入内容

  $> ./ configure

  而不是

  $> ./ configure --prefix = / home / veryambitious / local

  在你的腰带上有一些成功的构建，你引用的指示变得清晰如泥 . 对于 sysroot ，sysroot确定mypath的位置 - 您只需要担心要在哪里构建编译器，安装它并运行它 . 正如我之前所说的那样，你想要这样做的目的（除了让一个's up-to-date: There are a lot easier ways of accomplishing that, and getting the latest bugfixes, too). If your goal is just to have a native compiler that'是最新的，我想不出有任何理由在系统根目录这么做 - 在某个地方的顶部您计划调用系统root的层次结构或挂载点 . 当我使用CMake（GNU自动工具的潜在竞争对手，但不是GNU产品，尤其是gcc），它将默认安装目录指定为 C:\Program Files\somewhere - I 'm sure that' sa 'de facto'某人的标准 .

  您的来源最终在您的机器上取决于您如何获得它 . 路径中带有“trunk”的一个版本是svn-gcc，它将从subversion CMS存储库中检索 . 如果你有一些tarball版本，你的树可能会有所不同 . subversion树将包含许多你不会在“目标tarball”中获得的东西，就像已经为你的环境设置的构建树一样 . 但是，由于它是为软件配置管理而维护的，因此它将经常通过最新的更改进行维护 . 有时，工具构建器会添加单独的“工作快照”来复制某个典型环境的结果 .

  对于符号链接，这对于符号链接来说真的是一个很好的名称，我甚至不确定它在Windows7版本中转换为NT 4.0 . 符号链接不是硬链接，因为它在inode或文件系统实体的定义中不起强大作用 . 符号链接是一个轻量级链接，可以删除和更改，而不会真正影响原始文件 . 作者所说的关于使用* x86_64-w64-mingw32 *子树的链接构建gcc的原因是，您将在构建中使用的文件可以被赋予通用别名，而无需构建完全不同的子树来获取它们 .

  您的配置错误是更通用的vanilla错误消息之一，它说的是一些东西，而不是什么都不说，让您弄清楚您错过了大部分需要的东西 . 这意味着，"I can't tell you what went wrong, but I can't find anything that I need to begin to read and produce files. This must be a weird environment because I don't see anywhere to read or write. Maybe you missed the header files -- are you sure you put them in the right place(s)? If not, maybe this is a machine, operating system, or environment that hasn't been defined for me."这确实出现在现实生活中，因为人们在一台将在另一台机器上托管的机器上构建交叉编译器 . 或者用于将托管在另一台计算机上的代码 . 在这些情况下，您需要添加 configure 选项--build = mybuild（请不要问我在哪里）和--host = myhost .

  通常它只是意味着你做错了，你必须按照 Build 与整个配置相匹配的gcc的说明 . 有很多方法可以做到这一点 - 你提到MINGW，但这不是全部 . 您需要来自Windows API的内部函数 . Cygwin DLL中包含了很多这些 - 我不知道是否有人正在研究它 . MSYS 使用类似的方法，但不提供完整的cygwin集 . 您没有UNIX系统例程，因此您需要进行一些替换 - 在Linux上比在Windows上更容易提供 .

  您的目标将生成可在MSVCRT（Microsoft Visual C运行时）的帮助下运行的可执行文件，这是标准结果中的另一个问题 . 有时即使您拥有最新的GCC，MSVCRT还没有赶上 . 有时他们只是选择忽略标准，例如，格式转换字符串的大小参数 - 也许他们认为你应该定制流 - 谁知道？

  我想我会将此标记为社区帖子，因为我确信我很有可能设法输入极其愚蠢的东西 . 我希望我已经阐明了如何在Windows上编译GCC并不是一个“开箱即用”的努力 . 我无法覆盖所有这些，所以我只是用线索散落在这个页面上 .

  回复于 2024-05-03T21:02:50+08:00