如果你必须有一个最小的 Gnu-Windows 64 位 Gnu 编译器集合，我认为你应该检查 MinGWTDM64。如果您担心 MinGW32 不适合您的目的，那么您可能被误导了（尽管我无法确定您想要做什么，或者它是否可能）。但是我发现 TDM（Dragon？）在保持最新状态方面做得比 mingw 组织本身（至少最近）做得更好。
如果您不能遵循以上内容，我认为它更适合您，因为以上内容在很大程度上反映了 * nices 的 FSSTND（文件系统层次结构）标准。配置工具是 GNU 构建系统的一部分（请尝试一下 Wikipedia），因此了解它需要知道它期望在预定路径上找到哪些源文件以及在哪里编写其目标文件。这将引导您在您的环境（或平台、机器、操作系统等）中为您的编译设置正确的头文件，以便它生成一个可以为您正确运行的产品（编译器）。
因为 Gnu 不是 Unix (GNU)，而 Windows 肯定不是，所以从单个工具集生成一个可以在其中任何一个上工作的编译器是复杂的（阅读“易碎”）。构建编译器也不是开发人员职业生涯的第一步。因此，除非您准备好在血腥的小路上无休止的心碎（如果可以允许我打个比方的话），请在我建议购买现成的包裹时再次幽默。
我劝阻你了吗？不，好吧，别说我没试过。构建工具对编译的重要性在于它configure本身就是由它们构建的。经常有一组安装说明（GNU 要求），上面写着“构建这个包（让我们说“Hello, World”以将它保持在一个相当安全的营地），你必须首先运行
$> ./配置
其次是
$> make
这本身就是一个严重的过度简化，因为任何一个都可能采用各种参数来确定您打算使用的编译器的类型和位置以及您打算安装产品的位置。但是，让我们不要分歧太大。在许多这些包中，说明会继续说，“configure是使用 autotools 集构建的，但您不必重新构建它来编译这个版本的helloworld。”
恕我直言，“不应该”总是应该大写、斜体、粗体强调并尽可能多地重复。很多时候，只有当您拥有与作者相同的平台（架构、处理器、操作系统和环境）时，才不需要重构配置。如果你很幸运并且作者是彻底的，即使作者最初是在 linux 机器上构建的 ，你偶尔也会在 windows 机器上对helloworld进行干净编译。
我不建议构建 GCC（mingw32、64 或其他任何风格）的一个重要原因是，我不建议您在没有生成自己的 GNU 发行版的情况下尝试理解 autotools（即使它只是为了练习）。好吧，你问，“如果我还没有编译器，我应该怎么做？” 我能理解你的沮丧，甚至在一定程度上分享它。
如果您仍然希望自己将这个编译器套件放在 Windows 机器上（不使用 MinGWTDM 等），您应该首先让它在家里的 Linux 环境中运行。一旦你看到一个构建在那里是如何工作的，它就会变得更加清晰。尽管如此，我仍然看不到您对完整编译器集（甚至是 C 编译器，真的）进行干净编译的任何可能性。哈佛大学的 David Malan 使用虚拟化环境远程教授 CS50，这些虚拟环境感觉非常类似于实际安装。它是免费的，他甚至在此过程中教授 C，这将使您了解编译器选项（对于在不同环境中构建至关重要）。
如果您不想运行虚拟化，或者您没有获得构建虚拟机的说明（比构建编译器更容易，信不信由你），您可以在某个地方安装一些品牌的 Linux。尽管有可能进行双重引导，但我不建议在您的 Windows 机器上执行此操作，因为它可能比构建编译器或虚拟机更具破坏性。
这样做并从 Sourceforge 下载一些 Linux 源代码包（强烈推荐——您不想要错误的配置或构建脚本）。按照说明进行操作。在 Linux 上构建它们，然后在 Windows 上重复该过程（您可以使用 32 位编译器来完成，除非有人告诉您不能 [99.9% 的时间]）。
转到其中一个autotools/autoconf教程（不是手册页，稍后再做以了解该练习的详细含义）。把你自己的helloworld包放在一起，制作你自己的包，configure这样你就知道它在做什么。首先在 Linux 下进行以确保更大的成功机会——然后将其“移植”到 Windows。智者的话——避免任何带有信号的东西——它们没有在 Windows 下实现，我什至不确定我的想法是否会奏效。
说了这么多，我要说一些更烦人的话：虽然 mingw-w64-howto-build.txt 写得不是特别好，但它并不像在新手眼中看起来那么糟糕。事实上，我会说它不是为新手观众而写的。由于从源代码构建编译器的过程（尤其是在其原始位置之外）并不是一件小事，如果您能找到任何人可以在不使用太多相同词汇的情况下向您解释它，我会感到惊讶。做这种事情的人彼此交谈的方式完全相同。他们的写作工作通常比上面的要差得多——除非是在代码和构建脚本方面。
但是，如果您没有选择更容易实现的方法，@prefix@或者在脚本中首先调用的任何内容都是一种“主树”（a）用于构建源，（b）用于构建目标和（ c) 用于构建安装。Unix 是基于 MULTICS 的，这提醒了比尔盖茨在微软开发 XENIX 之前的工作，这三个都是“多用户操作”或“处理器控制系统”。多用户包含多个帐户、多个角色和多个构建/安装树的概念。
为自己构建编译器——尤其是在构建的最后一部分是安装过程的情况下——将不同于为同一台机器的其他用户构建它。让我们进一步扩展这个概念：假设您不是为自己和您的朋友做这件事——您是为您的公司或更可能是“您的安装”做这件事。在这种情况下，您的安装将类似于您部署的基础：您不仅需要担心为您和在您的机器上拥有帐户的朋友构建编译器 - 您还必须担心为您的老板构建它，你的操作员、你的管理员、你的程序员、你的设计师——以及其他任何可能想要/需要编译器来完成他们的工作的人。您可能有几种必须共存的编译器，
构建和安装树将有许多共同点。 PREFIX试图解决这个问题。当我为自己的小沙箱构建时，我使用了一个我设置的前缀，称为~/local. 那是* nices的特殊位置。~ 是 Windows 术语中 $HOME 或 %home% 的快捷方式。这是您练习构建的最佳场所。它应该不需要特殊权限，但可能存在一些限制。 PREFIX并不能解决所有问题，但它让配置工具了解您将构建和安装树的根目录。用 David Malan 的话来说，如果我要在其中构建代码/home/jharvard/local/<product name>/src（并且某些工具的某些版本会坚持使用完整路径而不是通常的快捷方式~/<product name>/src），我PREFIX的沙箱编译将是~/local或者/home/jharvard/local，给定一个合理的文件系统标准命名约定，您的可执行文件（生成的和/或现有的）将在~/local/bin您的库中，并且当您在自己的帐户中使用它时~/local/lib，您的包含标头将在其中。~/local/include这些东西是如何进入这些目录的？你在那里建造了一切。您可能从 mingw-w64-howto-build.txt 文件中引用的源中借用了诸如标头之类的东西。
一些存活了一段时间的工具会被推广到更广泛的用户群：他们进入/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.
在只有 Gods 编译的系统根目录中，工具进入 /bin 本身，如果不是 /sbin ——这些子树可以在系统中以不同的目的在不同的树上找到—— like /usr/local/experimental/src, /usr/bullpen/development/etc, /usr/production/bin。
我认为人们选择不回答这样的帖子的原因变得越来越清楚，但由于各种各样的原因，这个练习可能对许多人有用。
至于什么是默认值，它是默认值——当你没有使用其他东西时，你知道你正在使用默认值。实际上，他告诉您默认值是什么，因为他告诉您“如果使用配置默认值/usr/local”，那么配置默认值PREFIX是/usr/local. 如果您不使用其他任何内容，则表示您键入
$>./配置
而不是
$>./configure --prefix=/home/veryambitious/local
并且通过一些成功的构建，您引用的说明变得清晰如泥。对于sysroot，sysroot确定mypath的位置是——你只需要担心你想在哪里构建你的编译器，安装它并运行它。正如我之前所说，您想要这样做的目的（不仅仅是拥有一个最新的：有很多更简单的方法可以实现这一点，并获得最新的错误修正）。如果您的目标只是拥有一个最新的本机编译器，我想不出有任何理由在系统根目录下进行 - 在层次结构的顶部或您计划调用的挂载点系统根。当我使用 CMake（GNU autotools 的潜在竞争对手，但不是 GNU 产品，尤其是 gcc）构建时，它将默认安装目录指定为C:\Program Files\somewhere- 我确信这对某人来说是“事实上的”标准。
您的资源最终在您的机器上的位置取决于您如何获取它。路径中带有“trunk”的一个版本是 svn-gcc，它可以从 subversion CMS 存储库中检索。如果您有某个版本的 tarball，您的树可能会有所不同。颠覆树将包含很多你不会在“目标压缩包”中获得的东西，比如已经为你的环境设置的构建树。但是，由于它是为软件配置管理而维护的，因此将经常使用最新的更改对其进行维护。有时，工具构建者会添加单独的“工作快照”来复制某个典型环境的结果。
至于符号链接，对于符号链接来说，这确实是一个*好名字，我什至不确定它是否会在其 Windows7 化身中转换为 NT 4.0。符号链接不是硬链接，因为它在 inode 或文件系统实体的定义中没有发挥重要作用。符号链接是一种轻量级链接，可以删除和更改而不会真正影响原始文件。作者所说的关于使用 *x86_64-w64-mingw32* 子树的链接构建 gcc 的意思是，您将在构建中使用的文件可以被赋予通用别名，而无需构建完全不同的子树来获取它们。
您的配置错误是更通用的普通错误消息之一，它说明了一些事情，而不是什么都不说，让您发现您缺少大部分您需要的东西。它的意思是，“我不能告诉你出了什么问题，但我找不到开始读取和生成文件所需的任何东西。这一定是一个奇怪的环境，因为我看不到任何可以读取或写入的地方。也许你错过了头文件——你确定你把它们放在了正确的地方吗？如果没有，也许这是一个没有为我定义的机器、操作系统或环境。这在现实生活中确实出现了，因为人们在一台机器上构建交叉编译器，然后托管在另一台机器上。或者对于将托管在另一台机器上的代码。在这些情况下，您需要添加configure选项 --build=mybuild（请不要问我那在哪里）和 --host=myhost。
通常这只是意味着您做错了，您必须按照说明构建与您的整个配置相匹配的 gcc。有很多方法可以做到这一点——你提到了 MINGW，但这还不是全部。您需要来自 Windows API 的内部函数。Cygwin DLL包含了其中的一堆——我不知道是否有人正在研究它。 MSYS使用类似的方法，但不提供完整的 cygwin 集。您没有 UNIX 系统例程，因此您需要一些替换——在 Linux 上比在 Windows 上更容易提供。
您的目标将生成可执行文件，这些可执行文件将在 MSVCRT（Microsoft Visual C 运行时）的帮助下运行，这是标准结果中的另一个问题。有时即使您拥有最新的 GCC，MSVCRT 也没有赶上。有时他们只是选择忽略标准，比如格式转换字符串的大小参数——也许他们认为你应该自定义流——谁知道呢？
我想我会将此标记为社区帖子，因为我确信我很有可能设法输入了一些极其愚蠢的东西。我希望我已经阐明了如何在 Windows 上编译 GCC 不会成为“开箱即用”的努力。我无法涵盖所有内容，所以我只是在这一页上乱扔线索。