為什麼用多核編譯就會報錯

A. c++程序用g++編譯能通過，但在運行的時候卻出現Segmentation fault(核心已轉儲)錯誤，請問該怎麼解決

寫錯了唄

v1.begin() != v1.end() 是什麼鬼

B. vc6.0編譯錯誤

這個是我以前搜到的，是針對這個問題的 不過我沒出現過這種問題 能不能弄好看你自己了 我也不清楚：

很多人在使用VC++ 6.0編譯的時候出現如下問題:

"Compiling... ,Error spawning cl.exe」

很多人的選擇是重裝，但卻仍難解決。

解決：打開vc界面,點擊VC 」TOOLS（工具）" -> "Option（選擇）" -> " Directories（目錄）」重新設置「Executable Files、Include Files、 Library Files、Source Files」的路徑。很多情況可能就一個盤符的不同

如果你是按照初始路徑安裝vc6.0的，路徑應為：
executable files:
C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
C:\Program Files\Microsoft Visual Studio\VC98\BIN
C:\Program Files\Microsoft Visual Studio\Common\TOOLS
C:\Program Files\Microsoft Visual Studio\Common\TOOLS\WINNT

include files:
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE

library files:
C:\Program Files\Microsoft Visual Studio\VC98\LIB
C:\Program Files\Microsoft Visual Studio\VC98\MFC\LIB

source files:
C:\Program Files\Microsoft Visual Studio\VC98\MFC\SRC
C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\CRT\SRC

以上是該問題的核心，但卻不是本文談的主題，寫這篇文章主要是想解釋下為什麼會這樣，表達一下對網友們談的一些問題的看法

根本原因是cl.exe引起的，那我們就先來談談它。
「cl.exe」是VC使用真正的編譯器（編譯程序），其路徑在 " VC根目錄\VC98\Bin 」下面，
你可以到相應的路徑下找到這個應用程序。以上羅列的需要修改的路徑中，其實你只要改了
"Microsoft Visual Studio\VC98\BIN」，就可以使vc找到它了。雖然這么簡單，問題就解決了，但你未必能編譯！畢竟萬物都是有聯系的，vc又怎麼能開這個先例呢？！
這就涉及到其它目錄的作用，學過點兒語言的，一眼就能分辨include，library，source的作用，這里就不在贅敘了。只撿最重要的說（肯定是與cl.exe最親的了）。
C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin中含有mspdb60.dll這個動態鏈接庫，而執行cl.exe必須擁有它才行。讀者可以到cl.exe的所在目錄裏手動執行下它，就會發現它無法執行，系統提示"找不到mspdb60.dll」。（顯然它們不是一家的）

接著來談網上的「故事」
網上的說法可謂五花八門，挑些典型的且記憶猶新的來說吧！
1. 中英文之說
眾所周知，存在中文版的vc，所以有說法是中文版本引起的。答案是否定的，首先英文版也會有這種現象（造成原因，後文會解釋），其次漢化只是表面漢化（編譯反饋的信息基本都是英文，說比例是99%也不過分。很明顯，基本停留在菜單級別），不觸及核心，此類問題又從何談起呢？
2. 按鈕選擇"compile」 , "build」 , "executable program」
有人說，不要用」compile」，直接後兩者就行。有點常識也會知道，肯定不是這回事，build的中已經隱含了compile.不用多說，不攻自破。
3. 環境變數中的Path
這個說法比較像,尤其是聯想到java配置編程環境時的問題,所以我考慮得最久。當然它還是不成立的，最直接的解釋，vc安裝後不會對環境變數做任何修改，就可以直接使用。換個角度再來談談，path值主要用於查找程序執行時所需的.dll，在上文我們已經提到如果找不到"mspdb60.dll」，會無法編譯，但絕不是此文談論的。何況vc又不對path干預呢？

最離奇的莫過於有人路徑改對了，卻仍然無效。當然這種說法我看到的少之又少，但還
是決定說一說。首先在我的圈子中，並未發現過這樣的問題，所以我很難給予准確的解釋。但有這樣一個現象值得注意，有人把 "Error executing cl.exe」 誤當成了"Error spawning cl.exe"還在「喊冤」，前者完全是因為程序的錯誤，比如某個變數重復定義了，再如定義結構體模板後沒跟分號等等。所以在出現上述情況，請仔細核對。

還有人提到，更改路徑後，重啟vc後路徑還原。同上，我還是沒碰到過，但我所確定
的是在我的測試中沒發生過。有種特例，你在更改路徑後，編譯程序出現假死（自更改路徑至今，還沒重啟），然後你調用資源管理器kill掉進程（常用vc的人可能會很熟悉這個不是bug的bug），這時你重啟路徑肯定會是原狀，你也肯定知曉其中的123。

最後說明下，出現這種問題的原因。
多半在你重裝vc時產生，尤其是你只是把從前vc目錄的所有文件都刪了，然後貿然重裝。還要提到的是，即使你把注冊表關於vc的數據處理了，你安裝新的，它還會找你麻煩。這也是我沒想明白的：vc沒通過注冊表干擾新的安裝，那是通過什麼呢？（一般程序都是通過注冊表限制）
此後，一直在考慮vc怎麼做到及怎樣避免此類問題。直到昨晚，雅典娜終於眷顧了我。
最好的重裝辦法是使用官方的卸載程序先卸載，例如通過「添加刪除程序」。先別急重裝，細心的人會發現卸載不「干凈」，還會留下"common」，"my program」（為簡便，我省略了它們的上級目錄）。首先解釋為什麼卸不「干凈」，這類文件中存放的是用戶的編程信息（當然了，前提是使用了程序默認保存路徑），也就是你寫的程序。防止你沒有備份，當然不卸了，很多軟體都有此類功能。這也解釋了，我的疑問，vc安裝時會尋找原有安裝目錄，如果你沒有幹得干凈，那你重裝完就會出現路徑問題。
那官方卸載後，這個兩個目錄不刪行不？答案是肯定，你更可方便的用新的vc調用原來的程序。
安裝時只會出現：
"A previous installation of Visual SourceSafe was detected at: X:\Microsoft Visual Studio\Common\VSS\ Select YES to replace it with VSS 6.0 or NO to install VSS 6.0 to its default location Y N"

所以放他一馬也不為過。
終於散場了…

由於時間倉促，水平有限，只能及此。歡迎指正錯誤，共同成長。

C. C語言編譯時總是出現Error spawning cl.exe有什麼解決方案嗎

方法1：
啟動VC時不要用圖形界面,通過在命令提示符下輸入:Msdev /useenv運行（注意啦/前面有個空格）.它會強制使系統環境變數全高設置成正確值.而且,只需要使用一次這樣的方式運行VC,以後再次通過雙擊圖標的方式啟動也不會有問題。

方法2：
使用VC安裝盤修復一下。

方法3：
在VC中點擊「Tools」—>「Option」—>「Directories」，發現路徑有誤，重新設置「Excutable Fils，Include Files，Library Files，Source Files」的路徑。

要是顯示「找不到mspdb60.dll」，去能正常運行VC++的電腦中搜索mspdb60.dll文件，拷貝到機器上Microsoft Visual Studio\Common\MSDev98\Bin下。缺失其他文件類似操作。

方法4：
可能很多人在安裝VC 6.0後有過點擊「Compile」或者「Build」後被出現的
「Compiling... ,Error spawning cl.exe」錯誤提示給郁悶過。很多人的
選擇是重裝，實際上這個問題很多情況下是由於路徑設置的問題引起的，
「CL.exe」是VC使用真正的編譯器（編譯程序），其路徑在「VC根目錄\VC98\Bin」下面， 可以到相應的路徑下找到這個應用程序。

D. 編譯linux3.5內核報錯，這個什麼問題

內核編譯，需要先配置內核，你需要編哪些東西或模塊，生成.config文件。先make defconfig 或者make menuconfig（圖形配置界面），再make。

E. Xcode無法編譯，一運行就報錯，請問如何解決

1、XCode默認使用與CPU核數相同的線程來進行編譯，但由於編譯過程中的IO操作往往比CPU運算要多，因此適當的提升線程數可以在一定程度上加快編譯速度。
2. 將Debug Information Format改為DWARF 在工程對應Target的Build Settings中，找到Debug Information Format這一項，將Debug時的DWARF with dSYM file改為DWARF。 這一項設置的是是否將調試信息加入到可執行文件中，改為DWARF後，如果程序崩潰，將無法輸出崩潰位置對應的函數堆棧，但由於Debug模式下可以在XCode中查看調試信息，所以改為DWARF影響並不大。這一項更改完之後，可以大幅提升編譯速度。
3. 將Build Active Architecture Only改為Yes 在工程對應Target的Build Settings中，找到Build Active Architecture Only這一項，將Debug時的No改為Yes。 這一項設置的是是否僅編譯當前架構的版本，如果為No，會編譯所有架構的版本。需要注意的是，此選項在Release模式下必須為Yes，否則發布的ipa在部分設備上將不能運行。這一項更改完之後，可以顯著提高編譯速度。

F. 編譯內核時出現這種問題是什麼情況

、若編譯內核時總是出現同一個錯誤，如下：
在make moles_install時最後幾行彈出錯誤：
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.12.2; fi
/bin/sh: line 1: 3357 已殺死 /sbin/depmod -ae -F System.map 2.6 .12.2
make: *** [_modinst_post] 錯誤 137
如果繼續make install,重啟，是進不去剛剛編譯安裝的那個內核的，顯示內核錯誤。
分析：如果 System.map可讀 並且 /sbin/depmod可執行；那麼就執行/sbin/depmod -ae -F System.map 2.6.20;結束
depmod（depend mole）
功能說明：分析可載入模塊的相依性。
語 法：depmod [-adeisvV][-m <文件>][--help][模塊名稱]
補充說明：depmod可檢測模塊的相依性，供modprobe在安裝模塊時使用。
參 數：
-a或--all 分析所有可用的模塊。
-d或debug 執行排錯模式。
-e 輸出無法參照的符號。
-i 不檢查符號表的版本。
-m<文件>或system-map<文件> 使用指定的符號表文件。

G. make命令編譯內核出現錯誤

安裝下內核的header包吧。每個內核版本都有對應的。

H. 編譯內核模塊錯誤（linux）

在這些高版本的RedHat Linux上，我們如果需要定製內核的話，沒有直接的源代碼rpm可以安裝，只能通過kernel.org下載的tar.gz的包手工安裝，或者通過kernel-*.src.rpm編譯出kernel-source包再來安裝。後面一種方法可以享受到RedHat針對內核的某些參數和代碼的優化，因此對使用RedHat發行版特別是企業版本的，是有一定好處的。
但是目前很多人至今分不清內核，內核開發，內核源代碼一些包之間的關系，因此在編譯內核的時候經常走彎路，同時RedHat官方對於如果得到kernel-source也沒有明確的指示，導致很多人不得要領。

首先認清楚各rpm包的內容和用途
kernel-*.rpm ------------- 內核二進制包，沒有的話系統都起不來
kernel-sourcecode-*.rpm------------------- 內核源代碼包，安裝到/usr/src/linux-*下面的，包含內核源代碼，編譯內核必須（當然是不考慮用kernel.tar.gz編譯的情況），但高版本RedHat Linux不再提供此rpm，原因參見官方Release Note，這篇文章的最終目的就是要我們自己把這個包搞出來。
kernel-devel-*.rpm----------------內核開發包，安裝到/usr/src/kernels，用於內核模塊開發，組織形式跟內核源代碼包類似，包含了部分內核源代碼。注意很多人誤認為這個就是內核源代碼包，直接拿它來編譯內核，當然不可能成功。這個包只是用於內核模塊一級開發，例如驅動程序等，雖然也可以make menuconfig make dep等，但make bzImage是不可能成功的，因為缺失了核心源代碼。
kernel-*.src.rpm---------------RedHat提供的用於建立rpm的源代碼包，安裝到/usr/src/redhat中，使用rpmbuild可以從這個包中build出上面所說的所有包。

現在就來從src.rpm編譯出上面的所有的包，除了sourcecode這個包其他的包都可以在不用修改任何地方的情況下直接rpmbuild出來，唯有sourcecode這個比較麻煩，一定要按照下面的步驟來做，我以RedHat AS4 所帶的版本為例，其他版本相同。

#首先安裝src.rpm
rpm -ivh kernel-2.6.9-5.EL.src.rpm
#進入相應目錄，要修改spec文件
cd /usr/src/redhat/SPECS
vi kernel-2.6.spec
#主要修改如下地方：
1，define buildsource 0------------我的這個在第8行，改為1，這就是為什麼沒有源代碼包的原因，因為默認不生成源代碼包
2， Requires: qt-devel, gtk2-devel readline-devel ncurses-devel-------我的在572行，如果沒用用X的話，把這句注釋掉，這樣編譯出來的包就不依賴於X-window的某些包，因為內核配置是可以make xconfig的，所以默認依賴X-window，我沒裝X-window，因此這個就去掉了。
#保存退出
touch /etc/beehive-root
#這句命令非必須，如果不做的話，最後編譯出來的包都會變成kernel-*.*-root.rpm，多了個root，據說是為了標示包的編譯人的，如果touch了這個文件，就沒有這個問題了，命名和官方rpm一樣。
rpmbuild -ba --target=i686 ./kernel-2.6.spec
#編譯i686平台的所有包，這樣上面介紹的所有包都會生成，或者換成rpmbuild -bb --target=i686 ./kernel-2.6.spec只編譯非src.rpm。
#所有包就會生成到/usr/src/redhat/RPMS/i686下面

#如果只需要sourcecode而並非所有rpm包，那在修改spec文件時還要修改如下行：

48 %ifarch noarch
49 %define builddoc 1
50 %define buildsource 0----------------這里0修改為1
在編譯的時候使用rpmbuild -ba --target=noarch ./kernel-2.6.spec，這樣僅僅編譯soucecode和doc包，會節省很多時間。

注意，此篇文章所講所有內容僅適用於使用2.6內核的新版本RedHat Linux，2.4版本內核代碼組織方式不同，不適用此文章。

以上這篇文章取自互聯網,我忘了出處,尊敬作者.

I. 在高版本內核上編譯的程序在低版本內核運行會崩潰

glibc主版本號。
而且編譯的時候如果CGFLAGS和CXXFLAGS如果沒有-g選項的話用gdb調試無法看到變數名，默認是提示有問題。