㈠ 用高版本編譯低版本gcc的問題
據說要低版本的才能編譯高版本的
㈡ 裝了兩個版本的GCC，怎麼規定用哪一個
如果你的兩個版本的 gcc C 編譯器是安裝在不同的路徑下的話，那麼就很好辦：你可以在環境設置文件中修改 PATH 環境變數：假設：環境設置文件的文件名為：my_environment，gcc version 1 是安裝在 /usr/sbin1 下的話，gcc version 2 是安裝在 /usr/sbin2 下的話，那麼你就可以編輯 my_environment 文件，並修改其中的 PATH 變數。
例如：PATH = /usr/sbin2 ; /usr/sbin1，/usr/sbin1 在 /usr/sbin2 之後。這樣的話，系統就會自動調用 /usr/sbin2 下的 gcc 編譯程序。如果想使用 gcc version1版本的編譯程序，則再次修改該變數即可。
㈢ linux中gcc編譯器如何使用
2004年4月20日最新版本的GCC編譯器3.4.0發布了。目前，GCC可以用來編譯C/C++、FORTRAN、java、OBJC、ADA等語言的程序，可根據需要選擇安裝支持的語言。GCC 3.4.0比以前版本更好地支持了C++標准。本文以在Redhat Linux上安裝GCC3.4.0為例，介紹了GCC的安裝過程。
安裝之前，系統中必須要有cc或者gcc等編譯器，並且是可用的，或者用環境變數CC指定系統上的編譯器。如果系統上沒有編譯器，不能安裝源代碼形式的GCC 3.4.0。如果是這種情況，可以在網上找一個與你系統相適應的如RPM等二進制形式的GCC軟體包來安裝使用。本文介紹的是以源代碼形式提供的GCC軟體包的安裝過程，軟體包本身和其安裝過程同樣適用於其它Linux和Unix系統。
系統上原來的GCC編譯器可能是把gcc等命令文件、庫文件、頭文件等分別存放到系統中的不同目錄下的。與此不同，現在GCC建議我們將一個版本的GCC安裝在一個單獨的目錄下。這樣做的好處是將來不需要它的時候可以方便地刪除整個目錄即可（因為GCC沒有uninstall功能）；缺點是在安裝完成後要做一些設置工作才能使編譯器工作正常。在本文中我採用這個方案安裝GCC 3.4.0，並且在安裝完成後，仍然能夠使用原來低版本的GCC編譯器，即一個系統上可以同時存在並使用多個版本的GCC編譯器。
按照本文提供的步驟和設置選項，即使以前沒有安裝過GCC，也可以在系統上安裝上一個可工作的新版本的GCC編譯器。
1. 下載
在GCC網站上（）或者通過網上搜索可以查找到下載資源。目前GCC的最新版本為 3.4.0。可供下載的文件一般有兩種形式：gcc-3.4.0.tar.gz和gcc-3.4.0.tar.bz2，只是壓縮格式不一樣，內容完全一致，下載其中一種即可。
2. 解壓縮
根據壓縮格式，選擇下面相應的一種方式解包（以下的「%」表示命令行提示符）：
% tar xzvf gcc-3.4.0.tar.gz
或者
% bzcat gcc-3.4.0.tar.bz2 | tar xvf -
新生成的gcc-3.4.0這個目錄被稱為源目錄，用${srcdir}表示它。以後在出現${srcdir}的地方，應該用真實的路徑來替換它。用pwd命令可以查看當前路徑。
在${srcdir}/INSTALL目錄下有詳細的GCC安裝說明，可用瀏覽器打開index.html閱讀。
3. 建立目標目錄
目標目錄（用${objdir}表示）是用來存放編譯結果的地方。GCC建議編譯後的文件不要放在源目錄${srcdir]中（雖然這樣做也可以），最好單獨存放在另外一個目錄中，而且不能是${srcdir}的子目錄。
例如，可以這樣建立一個叫 gcc-build 的目標目錄（與源目錄${srcdir}是同級目錄）：
% mkdir gcc-build
% cd gcc-build
以下的操作主要是在目標目錄 ${objdir} 下進行。
4. 配置
配置的目的是決定將GCC編譯器安裝到什麼地方（${destdir}），支持什麼語言以及指定其它一些選項等。其中，${destdir}不能與${objdir}或${srcdir}目錄相同。
配置是通過執行${srcdir}下的configure來完成的。其命令格式為（記得用你的真實路徑替換${destdir}）：
% ${srcdir}/configure --prefix=${destdir} [其它選項]
例如，如果想將GCC 3.4.0安裝到/usr/local/gcc-3.4.0目錄下，則${destdir}就表示這個路徑。
在我的機器上，我是這樣配置的：
% ../gcc-3.4.0/configure --prefix=/usr/local/gcc-3.4.0 --enable-threads=posix --disable-checking --enable--long-long --host=i386-redhat-linux --with-system-zlib --enable-languages=c,c++,java
將GCC安裝在/usr/local/gcc-3.4.0目錄下，支持C/C++和JAVA語言，其它選項參見GCC提供的幫助說明。
5. 編譯
% make
這是一個漫長的過程。在我的機器上（P4-1.6），這個過程用了50多分鍾。
6. 安裝
執行下面的命令將編譯好的庫文件等拷貝到${destdir}目錄中（根據你設定的路徑，可能需要管理員的許可權）：
% make install
至此，GCC 3.4.0安裝過程就完成了。
6. 其它設置
GCC 3.4.0的所有文件，包括命令文件（如gcc、g++）、庫文件等都在${destdir}目錄下分別存放，如命令文件放在bin目錄下、庫文件在lib下、頭文件在include下等。由於命令文件和庫文件所在的目錄還沒有包含在相應的搜索路徑內，所以必須要作適當的設置之後編譯器才能順利地找到並使用它們。
6.1 gcc、g++、gcj的設置
要想使用GCC 3.4.0的gcc等命令，簡單的方法就是把它的路徑${destdir}/bin放在環境變數PATH中。我不用這種方式，而是用符號連接的方式實現，這樣做的好處是我仍然可以使用系統上原來的舊版本的GCC編譯器。
首先，查看原來的gcc所在的路徑：
% which gcc
在我的系統上，上述命令顯示：/usr/bin/gcc。因此，原來的gcc命令在/usr/bin目錄下。我們可以把GCC 3.4.0中的gcc、g++、gcj等命令在/usr/bin目錄下分別做一個符號連接：
% cd /usr/bin
% ln -s ${destdir}/bin/gcc gcc34
% ln -s ${destdir}/bin/g++ g++34
% ln -s ${destdir}/bin/gcj gcj34
這樣，就可以分別使用gcc34、g++34、gcj34來調用GCC 3.4.0的gcc、g++、gcj完成對C、C++、JAVA程序的編譯了。同時，仍然能夠使用舊版本的GCC編譯器中的gcc、g++等命令。
6.2 庫路徑的設置
將${destdir}/lib路徑添加到環境變數LD_LIBRARY_PATH中，最好添加到系統的配置文件中，這樣就不必要每次都設置這個環境變數了。
例如，如果GCC 3.4.0安裝在/usr/local/gcc-3.4.0目錄下，在RH Linux下可以直接在命令行上執行或者在文件/etc/profile中添加下面一句：
setenv LD_LIBRARY_PATH /usr/local/gcc-3.4.0/lib:$LD_LIBRARY_PATH
7. 測試
用新的編譯命令（gcc34、g++34等）編譯你以前的C、C++程序，檢驗新安裝的GCC編譯器是否能正常工作。
8. 根據需要，可以刪除或者保留${srcdir}和${objdir}目錄。
㈣ arm-linux-gcc交叉編譯器的製作，以及版本選擇問題。
，需要必須有足夠動經驗來支持。
另外，用 RH9 的都是高手，我想你的知識不需要來提問了吧？
1、在 PC 上編譯 arm 的程序當然需要較差編譯器，這個需要自己安裝，或者著現成的交叉編譯器環境，一般是一個特殊參數編譯出來的 gcc + binutils + glibc + linux-header。這個每個人動環境不同，一般都需要自己編譯一個，當然沒有特殊需求，也可以找現成的。不過很難找，因為這套環境還要和你動系統搭配，不然環境不匹配，連這個環境都不能運行，那就更談不上編譯東西了。
有關自己編譯搭建交叉編譯環境，可以看看一個特殊的 Linux 發行版 LFS 的分支： CLFS 。
2、移植分很多意思，移植有可能就意味著這套源代碼不能在目標系統上面編譯，需要你根據相應的知識去修改源代碼來讓這套代碼適應目標編譯器的要求，比如源代碼有 SSE4 的優化，這套程序在非 SSE4 CPU 上無法編譯運行，但目標機器連 SSE1 都不支持。那麼就需要移植。
或者移植僅僅是根據新的環境進行編譯，不需要進行源代碼修改，只需要進行一下編譯就能運行的程序，也可以稱為移植，就是從一個環境、架構 -》另一個環境、架構。都可以稱為移植，但真正的移植意味著修改程序源代碼來適應新環境。你說的這種移植是最簡單的移植。
3、決定目標硬體環境 -》搭建目標編譯器 -》製作目標環境（內核，基礎軟體庫）-》進行應用移植（移植需要的軟體、主應用程序）-》搭建系統文件系統 -》導入目標系統-》啟動目標系統&應用。說起來很簡單，因為這是完全沒有問題的條件下。
至於超級終端。那是用來控制目標系統的。目標系統有可能不能插鍵盤滑鼠顯示器，這就需要一個遠程網路鏈接來進行控制。以及通過遠程鏈接來發送數據。這都需要終端的支持。
虛擬機下面進行開發，不能發揮你的計算機的性能。而且因為隔著 VMware 的軟體模擬層，可能還不會很方便的讓你鏈接目標設備。
至於用 socket ，我還沒見到你的目標需要這個東西，因為所有的東西都是現成的源代碼。不需要你從 0 開始寫，當然你想自己寫一個系統內核，或者伺服器程序，或者全套的系統+應用，我絕對不攔你，但希望你寫完這套東西，能把源代碼發布出來。
ads 可以認為是一個支持環境，他本身不是一個系統的開發 SDK 。
-------------------------------------
ads 沒用過，印象里他還有模擬器，調試器什麼的程序。功能上要比 Linux 開發環境，WinCE 環境下面的東西更多更偏向於硬體方面，畢竟 ads 是 arm 出品的，不太可能偏向於軟體部分設計。Linux 和 WinCE 都是系統而不是硬體工具。
你可以認為交叉編譯器是一個應用程序，一個輸出器。把源代碼輸出為 arm 的代碼，這個應用程序的輸出，是靠他自己的環境，而不是當前系統的環境的。
當前系統的各個軟體的版本，不能影響交叉編譯器輸出的環境（理論上，現實有的時候總是從別的地方給你打擊……），交叉編譯器一般至少有 gcc 、binutils 、glibc 庫、linux kernel 頭文件。
在軟體需求上。
頭文件誰都不依賴，glibc 只需要內核頭文件，其他程序全都依賴於 glibc 。也就是所有程序都不依賴內核，僅僅是依賴於內核頭文件。
gcc 和 binutils 是把程序源代碼根據上面各個環節的需提供的功能來輸出為上面環節裡面的二進製程序。依賴你當前環境的，只有 gcc 和 binutils 兩個程序的執行、控制環節。只有他們兩個依賴的，而不是你的交叉編譯後的程序。
至於編譯器版本的選擇，新版本功能更好，舊版本兼容更好。
這個要看你的實際需要了。應用程序源代碼也調編譯器的，同時也依賴於軟體庫的功能。
arm 開發建議穩定、兼容優先。當然也可以嘗試最新的編譯環境，來獲取更好的優化（前提是還有什麼代碼優化的話）。
另外,團IDC網上有許多產品團購,便宜有口碑
㈤ 怎樣指定某個版本的gcc來編譯程序
對於autotools來生成Makefile的程序包，不建亮輪議修改Makefile來指定GCC/G++的版本。
最佳方案：
./configure CC=你想使的C編譯器的絕對路徑
./configure CXX=你想使的C++編譯器的絕對路徑
比如：./configure CXX=/usr/local/bin/g++
這旁配樣就可以很方便地讓系統內多敬啟信個版本的編譯器共存了。
㈥ 關於gcc編譯選項選取動態庫不同版本的問題
不同版本的動態庫是為了升級方便，舊的程序需要與舊的庫鏈接，新的程序與新的．
一般的做法是把libabc.so連接(symbolic link, ln -s libabc.so.N libabc.so)到最新的版本，這樣以後的新程序，在用gcc -labc的時候，都會鏈接到新的版本．舊的已經鏈接好的程序並不會產生不兼容的問題，因為舊程序在過去已經鏈接過了（動態庫鏈接的信息可以用ldd來查看: ldd /bin/ls）．
symbolic link, ln是推薦的維護版本的辦法，不建議更改文件名．
如果你要有一個方便的辦法鏈接舊的版本, 建一個舊的版本的symbolic link就可以了,libabc11.so
ln -s libabc.so.11 libabc11.so
gcc -labc11...