如何在Windows上构建MinGW x64

Question

这里有一个问题: 如何构建MinGW W64

但是,没有答案.

我通过阅读mingw-w64-howto-build.txt完成了我的作业,但它根本没有写好.

以下是该文件的一部分:

==安装Mingw-w64标头集并创建所需的符号链接== [HDRSYM]

步骤1)标头的源目录可以是mingw-w64/trunk/mingw-w64-headers,或mingw-w64/mingw-w64-headers,具体取决于您的来源.

步骤2)创建另一个"构建"目录,然后输入它.要安装标头,请运行:../ path/to/configure --build =\--host = x86_64-w64-mingw32 --prefix =/mypath然后运行"make install"以安装标头.

什么是"前缀"？我应该在这里输入什么路径？

步骤3)GCC要求将x86_64-w64-mingw32目录镜像为同一根目录中的"mingw"目录.因此,如果使用configure default/usr/local,请键入:ln -s/usr/local/x86_64 -w64-mingw32/usr/local/mingw,或者对于sysroot,键入:ln -s/mypath/x86_64-w64-mingw32/mypath中/ MinGW的

我怎么知道我是否使用默认值？如果"/ usr/local/mingw"存在于我的系统中,它应该在哪里？到底是什么"mypath"？路径是什么？我在C:\ MinGW(应该用于构建此x64的那个)中安装了MinGW.这与这个符号链接有什么关系吗？

步骤4)手动创建x86_64-w64-mingw32/lib目录:mkdir -p/usr/local/x86_64-w64-mingw32/lib,或者对于sysroot:mkdir -p/mypath/x86_64-w64-mingw32/lib如果是已存在并且您收到错误,请忽略它.

对于sysroot？这是什么意思？

步骤5)符号链接x86_64-w64-mingw32/lib目录为x86_64-w64-mingw32/lib64:ln -s/usr/local/x86_64-w64-mingw32/lib/usr/local/x86_64-w64-mingw32/lib64或对于sysroot:ln -s/mypath/x86_64-w64-mingw32/lib/mypath/x86_64-w64-mingw32/lib64

对于sysroot？这是什么意思？#2

我自己尝试了一些东西,但结果如下:

configure:error:请检查mingw-w64标头集和build/host选项是否设置正确.configure:错误:../../mingw-w64-crt/configure为mingw-w64-crt失败

Answer 1

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

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

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

我劝你了吗？不,好吧,不要说我没试过.构建工具对编译的重要性在于它configure本身是由它们构造的.通常有一组安装说明(一个GNU要求),说"建立这个包(让我们说"Hello,World"让它保持在一个相当安全的阵营中)你必须先运行

$> ./configure

其次是

$> make

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

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

我建议不要建立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下进行,以确保更大的成功机会 - 然后"移植"到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.

在只有神编译的系统根目录下,工具进入/ 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自动工具的潜在竞争对手,但不使用GNU产品,尤其是gcc)进行构建时,它将默认安装目录指定为C:\Program Files\somewhere- 我确信这是某人的"事实上的"标准.

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

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

您的配置错误是更通用的vanilla错误消息之一,它说的是一些东西,而不是什么也不说,让您弄清楚您错过了大部分需要的东西.这意味着,"我不能告诉你出了什么问题,但我找不到任何我需要开始阅读和生成文件的东西.这一定是一个奇怪的环境,因为我看不到任何地方可以读或写.也许您错过了头文件 - 您确定将它们放在正确的位置吗？如果没有,可能这是一台尚未为我定义的机器,操作系统或环境.这确实出现在现实生活中,因为人们在一台将在另一台机器上托管的机器上构建交叉编译器.或者用于将托管在另一台计算机上的代码.在这些情况下,您需要添加configure 选项--build = mybuild(请不要问我在哪里)和--host = myhost.

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

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

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