Xcode工程設置裡面編譯器選項為啥沒有GCC?
如圖所示,在圖中的選項中只有Apple LLVM,難道Xcode7.0只支持這個編譯器,如果支持GCC,那又如何將GCC編譯器添加進來?(PS:剛接觸MAC不久)
曾經只有GCC,後來有LLVM和GCC同時存在,再後來從某個版本後就沒有GCC了.你依然可以在終端里敲"gcc",但實際上調出來的是LLVM.想安裝GCC得單獨安裝,用homebrew就行,但是若想在xcode里用,
需要裝xcode的一個擴展:頁面 ,這個已經很老了,不知道xcode7支持不,
另外即使裝上了很多庫用GCC也已經編不過去了.綜上,基本可以認為就是沒有,別折騰了....GCC編譯器不能滿足蘋果的許多特定需求,所以Xcode 5開始蘋果就不再在Xcode里內置GCC編譯器了(其實之前的版本內置的叫llvm-gcc,是LLVM的一個前端)。現在的Xcode可以手動從蘋果官網下載安裝llvm-gcc,但是版本太老沒有可用性。想把新版GCC集成到Xcode里需要用到國外開發者製作的插件,但是需要根據GCC版本手動修改插件里的一些文件名。單獨配置GCC也是可以的,不過不用Xcode開發應用畢竟很麻煩。
Xcode標準的編譯器Clang不支持很多語言,所以有些開發者習慣用GCC。不過現在Xcode就算手動集成了新版gcc也不能保證編譯出來的應用能穩定可靠運行在新設備上,所以最好的選擇就是不折騰。哎呀,抱歉才看到這個問題。我看過一篇比較詳細的解答:
作者已無從考究。。。作者抱歉~~——————請沿此虛線剪開——————————【GCC,LLVM,Clang編譯器對比】在XCode中,我們經常會看到這些編譯選項(如下圖),有些人可能會有些茫然,本文將對GCC4.2、LLVM GCC 4.2、LLVM compliler 2.0三個編譯選項進行一個詳細的介紹。
GCC
GCC(GNU Compiler Collection,GNU編譯器套裝),是一套由 GNU 開發的編程語言編譯器。它是一套以 GPL 及 LGPL 許可證所發行的自由軟體,也是 GNU計劃的關鍵部分,亦是自由的類Unix及蘋果電腦 Mac OS X 操作系統的標準編譯器。GCC 原名為 GNU C 語言編譯器,因為它原本只能處理 C語言。GCC 很快地擴展,變得可處理 C++。之後也變得可處理 Fortran、Pascal、Objective-C、Java, 以及 Ada與其他語言。LLVMLLVM 是 Low Level Virtual Machine 的簡稱,這個庫提供了與編譯器相關的支持,能夠進行程序語言的編譯期優化、鏈接優化、在線編譯優化、代碼生成。簡而言之,可以作為多種語言編譯器的後台來使用。如果這樣還比較抽象的話,介紹下 Clang 就知道了:Clang 是一個 C++ 編寫、基於 LLVM、發佈於 LLVM BSD 許可證下的 C/C++/Objective C/Objective C++ 編譯器,其目標(之一)就是超越 GCC。LLVM歷史Apple(包括中後期的NeXT) 一直使用GCC作為官方的編譯器。GCC作為開源世界的編譯器標準一直做得不錯,但Apple對編譯工具會提出更高的要求。一方面,是Apple對Objective-C語言(甚至後來對C語言)新增很多特性,但GCC開發者並不買Apple的帳——不給實現,因此索性後來兩者分成兩條分支分別開發,這也造成Apple的編譯器版本遠落後於GCC的官方版本。另一方面,GCC的代碼耦合度太高,不好獨立,而且越是後期的版本,代碼質量越差,但Apple想做的很多功能(比如更好的IDE支持)需要模塊化的方式來調用GCC,但GCC一直不給做。甚至最近,《GCC運行環境豁免條款 (英文版)》從根本上限制了LLVM-GCC的開發。 所以,這種不和讓Apple一直在尋找一個高效的、模塊化的、協議更放鬆的開源替代品,於是Apple請來了編譯器高材生Chris Lattner(2000年,本科畢業的Chris Lattner像中國多數大學生一樣,按部就班地考了GRE,最終前往UIUC(伊利諾伊大學厄巴納香檳分校),開始了艱苦讀計算機碩士和博士的生涯。在這階段,他不僅周遊美國各大景點,更是努力學習科學文化知識,翻爛了「龍書」(《Compilers: Principles, Techniques, and Tools》),成了GPA牛人【註:最終學分積4.0滿分】,以及不斷地研究探索關於編譯器的未知領域,發表了一篇又一篇的論文,是中國傳統觀念里的「三好學生」。他的碩士畢業論文提出了一套完整的在編譯時、鏈接時、運行時甚至是在閑置時優化程序的編譯思想,直接奠定了LLVM的基礎。LLVM在他念博士時更加成熟,使用GCC作為前端來對用戶程序進行語義分析產生IF(Intermidiate Format),然後LLVM使用分析結果完成代碼優化和生成。這項研究讓他在2005年畢業時,成為小有名氣的編譯器專家,他也因此早早地被Apple相中,成為其編譯器項目的骨幹)。剛進入Apple,Chris Lattner就大展身手:首先在OpenGL小組做代碼優化,把LLVM運行時的編譯架在OpenGL棧上,這樣OpenGL棧能夠產出更高效率的圖形代碼。如果顯卡足夠高級,這些代碼會直接扔入GPU執行。但對於一些不支持全部OpenGL特性的顯卡(比如當時的Intel GMA卡),LLVM則能夠把這些指令優化成高效的CPU指令,使程序依然能夠正常運行。這個強大的OpenGL實現被用在了後來發布的Mac OS X 10.5上。同時,LLVM的鏈接優化被直接加入到Apple的代碼鏈接器上,而LLVM-GCC也被同步到使用GCC4代碼。Clang歷史Apple吸收Chris Lattner的目的要比改進GCC代碼優化宏大得多——GCC系統龐大而笨重,而Apple大量使用的Objective-C在GCC中優先順序很低。此外GCC作為一個純粹的編譯系統,與IDE配合得很差。加之許可證方面的要求,Apple無法使用LLVM 繼續改進GCC的代碼質量。於是,Apple決定從零開始寫 C、C++、Objective-C語言的前端 Clang,完全替代掉GCC。
正像名字所寫的那樣,Clang只支持C,C++和Objective-C三種C家族語言。2007年開始開發,C編譯器最早完成,而由於Objective-C相對簡單,只是C語言的一個簡單擴展,很多情況下甚至可以等價地改寫為C語言對Objective-C運行庫的函數調用,因此在2009年時,已經完全可以用於生產環境。C++的支持也熱火朝天地進行著。下面這張圖將顯示GCC、LLVM-GCC、LLVM Compiler這三個編譯選項的不同點:對比作為一種新的編譯器,我們來看Clang和GCC各有什麼優缺點:Clang特性快:通過編譯 OS X 上幾乎包含了所有 C 頭文件的 carbon.h 的測試,包括預處理 (Preprocess),語法 (lex),解析 (parse),語義分析 (Semantic Analysis),抽象語法樹生成 (Abstract Syntax Tree) 的時間,Clang 是 Apple GCC 4.0 的 2.5x 快。(2007-7-25)內存佔用小:Clang 內存佔用是源碼的 130%,Apple GCC 則超過 10x。診斷信息可讀性強:我不會排版,推薦去網站觀看。其中錯誤的語法不但有源碼提示,還會在錯誤的調用和相關上下文的下方有~~~~~和^的提示,相比之下 GCC 的提示很天書。GCC 兼容性。設計清晰簡單,容易理解,易於擴展增強。與代碼基礎古老的 GCC 相比,學習曲線平緩。
基於庫的模塊化設計,易於 IDE 集成及其他用途的重用。由於歷史原因,GCC 是一個單一的可執行程序編譯器,其內部完成了從預處理到最後代碼生成的全部過程,中間諸多信息都無法被其他程序重用。Clang 將編譯過程分成彼此分離的幾個階段,AST 信息可序列化。通過庫的支持,程序能夠獲取到 AST 級別的信息,將大大增強對於代碼的操控能力。對於 IDE 而言,代碼補全、重構是重要的功能,然而如果沒有底層的支持,只使用 tags 分析或是正則表達式匹配是很難達成的。當然,GCC 也有其優勢:支持 JAVA/ADA/FORTRAN當前的 Clang 的 C++ 支持落後於 GCC,參見Clang - C++1z, C++14, C++11 and C++98 Status。(近日 Clang 已經可以自編譯,見LLVM"s Clang Now Can Build Itself)GCC 支持更多平台GCC 更流行,廣泛使用,支持完備GCC 基於 C,不需要 C++ 編譯器即可編譯要選擇哪個那麼三個編譯選項,要選擇哪一個呢?目前不推薦使用老的GCC4.2,因為蘋果不會維持它了,而且LLVM-GCC看起來會更好。在項目中途改編譯選項可是一個大變動,所以,如果你要改,當然需要經過慎重完整的測試。對新的項目而言,LLVM-GCC看起來應該是個安全的選擇,蘋果公司認為它夠穩定夠成熟,所以才把它當做Xcode 4的預設選項(你或許不會把穩定成熟這兩個字眼跟Xcode 4本身畫上等號),而且,既然選項使用的是GCC parser,向後兼容性應該沒問題。
我說LLVM-GCC是個安全的選項,但我並不是指Clang/LLVM比較不安全,只是成熟度還沒那麼高效了,我將一些以前的代碼拿到Xcode 4上,使用LLVM 2.0編譯器重新編譯,到目前為止還沒發現任何問題。參考文檔:gcc(GNU編譯器套件)http://www.programmer.com.cn/9436/apple需要定製編譯器以實現一些功能,比如O-c。llvm是一個現代編譯器框架,在編譯器各個階段很方便擴展。而GCC……據說能完全搞定的人,這世上越來越少了。。。
難道不是許可證的原因嗎?gcc 4之後採用GPLv3,對商業閉源應用限制更大。蘋果一怒之下甩開GCC,專心支持LLVM了。
Apple 現在已經不帶 GCC 了,系統中存在的 gcc, g++ 等程序都是指向 clang, clang++ 的。
推薦閱讀:
※clang分析源碼前判斷是按C模式還是按C++模式分析的過程?
※如果有一天,所有的 編譯器都消失了,人類應該如何最快恢復?
※編譯後的c/c++ 程序, 如何判斷一個函數 是否 真的inline了(如果不看反彙編話)?
※Swift,Haskell這種可以自定義運算符的語言(不僅僅是重載),在實現編譯器時跟其他語言又什麼區別嗎?