如何在 Windows 上構建 MinGW x64

Question

這里有一個這樣的問題： How to build MinGW W64

但是，沒有答案。

我通過閱讀 mingw-w64-howto-build.txt 完成了我的作業，但它根本寫得不好。

以下是該文件的一部分：

== 安裝 Mingw-w64 標頭集並創建所需的符號鏈接 == [HDRSYM]

步驟 1) 標頭的源目錄可以是 mingw-w64/trunk/mingw-w64-headers 或 mingw-w64/mingw-w64-headers，具體取決於您的源。

步驟 2) 創建另一個“build”目錄，然后輸入它。 要安裝頭文件，請運行： ../path/to/configure --build= \ --host=x86_64-w64-mingw32 --prefix=/mypath 然后運行“make install”安裝頭文件。

什么是“前綴”？ 我應該在這里輸入什么路徑？

步驟 3) GCC 要求將 x86_64-w64-mingw32 目錄鏡像為同一根目錄中的目錄“mingw”。 因此，如果使用配置默認 /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”，它應該在哪里？ “我的路徑”到底是什么？ 什么路徑？ 我在 C:\MinGW 中安裝了 MinGW（應該用於構建這個 x64 的那個）。 這與這個符號鏈接有什么關系嗎？

步驟 4）手動創建 x86_64-w64-mingw32/lib 目錄：mkdir -p /usr/local/x86_64-w64-mingw32/lib 或者，對於 sysroot：mkdir -p /mypath/x86_64-w64-mingw32/lib 如果它已經存在並且你得到一個錯誤，忽略它。

對於系統根？ 這是什么意思？

步驟 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

對於系統根？ 這是什么意思？ #2

我自己嘗試了一些東西，但結果是這樣的：

配置：錯誤：請檢查 mingw-w64 標頭設置和構建/主機選項是否設置正確。 配置：錯誤：../../mingw-w64-crt/mingw-w64-crt 配置失敗

Answer 1

如果你必須有一個最小的 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 不會成為“開箱即用”的努力。 我無法涵蓋所有​​內容，所以我只是在這一頁上亂扔線索。