为什么用多核编译就会报错

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调试无法看到变量名，默认是提示有问题。