binutils编译
简介
交叉编译工具链是一个由编译器、连接器和解释器组成的综合开发环境，交叉编译工具链主要由binutils、gcc和glibc 3个部分组成。有时出于减小libc库大小的考虑，也可以用别的c库来代替glibc，例如uClibc、dietlibc和newlib。交叉编译工具链主要包括针对目标系统的编译器gcc、目标系统的二进制工具binutils、目标系统的标准c库glibc和目标系统的Linux内核头文件。第一个步骤就是确定目标平台。每个目标平台都有一个明确的格式，这些信息用于在构建过程中识别要使用的不同工具的正确版本。因此，当在一个特定目标机下运行GCC时，GCC便在目录路径中查找包含该目标规范的应用程序路径。GNU的目标规范格式为CPU-PLATFORM-OS。例如，建立基于ARM平台的交叉工具链，目标平台名为arm-linux-gnu。
交叉编译工具链的制作方法
分步编译和安装交叉编译工具链所需要的库和源代码，最终生成交叉编译工具链。
通过Crosstool脚本工具来实现一次编译生成交叉编译工具链。
直接通过网上（ftp.arm.kernel.org.uk）下载已经制作好的交叉编译工具链。
方法1相对比较困难，适合想深入学习构建交叉工具链的读者。如果只是想使用交叉工具链，建议使用方法2或方法3构建交叉工具链。方法3的优点不用多说，当然是简单省事，但与此同时该方法有一定的弊端就是局限性太大，因为毕竟是别人构建好的，也就是固定的没有灵活性，所以构建所用的库以及编译器的版本也许并不适合你要编译的程序，同时也许会在使用时出现许多莫名的错误，建议你慎用此方法。
方法1：分步构建交叉编译工具链
下载所需的源代码包
建立工作目录
建立环境变量
编译、安装Binutils
获取内核头文件
编译gcc的辅助编译器
编译生成glibc库
编译生成完整的gcc
由于在问答中的篇幅，我不能细述具体的步骤，兴趣的同学请自行阅读开源共创协议的《Linux from scratch》，网址是：linuxfromscratch dot org
。
方法2:用Crosstool工具构建交叉工具链（推荐）
Crosstool是一组脚本工具集，可构建和测试不同版本的gcc和glibc，用于那些支持glibc的体系结构。它也是一个开源项目，下载地址是kegel dot com/crosstool。用Crosstool构建交叉工具链要比上述的分步编译容易得多，并且也方便许多，对于仅仅为了工作需要构建交叉编译工具链的你，建议使用此方法。
运行which makeinfo，如果不能找见该命令，在解压texinfo-4.11.tar.bz2，进入texinfo-4.11目录，执行./configure&&make&&make install完成makeinfo工具的安装
准备文件：
下载所需资源文件linux-2.4.20.tar.gz、binutils-2.19.tar.bz2、gcc-3.3.6.tar.gz、glibc- 2.3.2.tar.gz、glibc-linuxthreads-2.3.2.tar.gz和gdb-6.5.tar.bz2。然后将这些工具包文件放在新建的$HOME/downloads目录下，最后在$HOME/目录下解压crosstool-0.43.tar.gz，命
令如下：
#cd$HOME/
#tar–xvzfcrosstool-0.43.tar.gz
建立脚本文件
接着需要建立自己的编译脚本，起名为arm.sh，为了简化编写arm.sh，寻找一个最接近的脚本文件demo-arm.sh作为模板，然后将该脚本的内容复制到arm.sh，修改arm.sh脚本，具体操作如下：
# cd crosstool-0.43
# cp demo-arm.sh arm.sh
# vi arm.sh
修改后的arm.sh脚本内容如下：
#!/bin/sh
set-ex
TARBALLS_DIR=$HOME/downloads#定义工具链源码所存放位置。
RESULT_TOP=$HOME/arm-bin#定义工具链的安装目录
exportTARBALLS_DIRRESULT_TOP
GCC_LANGUAGES="c,c++"#定义支持C,C++语言
exportGCC_LANGUAGES
#创建/opt/crosstool目录
mkdir-p$RESULT_TOP
#编译工具链，该过程需要数小时完成。
eval'catarm.datgcc-3.3.6-glibc-2.3.2.dat'shall.sh--notest
echoDone.
建立配置文件
在arm.sh脚本文件中需要注意arm-xscale.dat和gcc-3.3.6-glibc-2.3.2.dat两个文件，这两个文件是作为Crosstool的编译的配置文件。其中arm.dat文件内容如下，主要用于定义配置文件、定义生成编译工具链的名称以及定义编译选项等。
KERNELCONFIG='pwd'/arm.config#内核的配置
TARGET=arm-linux#编译生成的工具链名称
TARGET_CFLAGS="-O"#编译选项
gcc-3.3.6-glibc-2.3.2.dat文件内容如下，该文件主要定义编译过程中所需要的库以及它定义的版本，如果在编译过程中发现有些库不存在时，Crosstool会自动在相关网站上下载，该工具在这点上相对比较智能，也非常有用。
BINUTILS_DIR=binutils-2.19
GCC_DIR=gcc-3.3.6
GLIBC_DIR=glibc-2.3.2
LINUX_DIR=linux-2.6.10-8(根据实际情况填写)
GDB_DIR=gdb-6.5
执行脚本
将Crosstool的脚本文件和配置文件准备好之后，开始执行arm.sh脚本来编译交叉编译工具。具体执行命令如下：
#cdcrosstool-0.43
#./arm.sh
经过数小时的漫长编译之后，会在/opt/crosstool目录下生成新的交叉编译工具，其中包括以下内容：
arm-linux-addr2linearm-linux-g++arm-linux-ldarm-linux-size
arm-linux-ararm-linux-gccarm-linux-nmarm-linux-strings
arm-linux-asarm-linux-gcc-3.3.6arm-linux-objarm-linux-strip
arm-linux-c++arm-linux-gccbugarm-linux-objmpfix-embedded-paths
arm-linux-c++filtarm-linux-gcovarm-linux-ranlib
arm-linux-cpparm-linux-gprofarm-linux-readelf
添加环境变量
然后将生成的编译工具链路径添加到环境变量PATH上去，添加的方法是在系统/etc/ bashrc文件的最后添加下面一行，在bashrc文件中添加环境变量
export PATH=/home/jiabing/gcc-3.3.6-glibc-2.3.2/arm-linux-bin/bin:$PATH
至此，arm-linux下的交叉编译工具链已经完成，现在就可以使用arm-linux-gcc来生成试验箱上的程序了！
㈡ Dev-C++如何升级编译器
升级很简单呀。
打开Dev-C++
Tools-->Check for updates/packages
按提示操作就可以了。
Check之后选中"binutils"包就能升级g++了。其它安装包可按需要选择。
目前升级之后的的binutils版本是：
2.15.94-20050118-1
其中g++版本是：
??(服务器太慢了，还没Down完。以后补充。)
㈢ 菜鸟求助，编译binutils
tar.gz的和TAR.BZ2大多是打包软件，大多是通过的./configure;使; make install的安装;有些软件直接进行;制作安装;
我们可以运行./configure - -help查看配置软件的功能;大部分的软件是提供的./configure配置软件的功能;和几个没有，如果没有，不要的./configure;直接进行;使安装就行了;
运行./configure更重要的参数是--prefix，用--prefix参数，我们可以指定软件安装目录;当我们不需要这个软件，这个软件直接删除就行了目录;
比如我们可以指定fcitx的安装到/ opt / fcitx的目录;.
[根@本地的fcitx]＃/配置--prefix =的/ opt / fcitx的
如果我们不fcitx的时候，你可以直接删除的/ opt / fcitx的目录;
所以我们举这个例子，fcitx的，如果自定义安装到/ opt / fcitx的目录中，完整的安装方法应该是：
[根@本地的fcitx]＃沥青jxvf fcitx- 3.2-050827.tar.bz2
[根@本地的fcitx] #CD fcitx的
[根@本地的fcitx]＃的./configure --prefix =的/ opt / fcitx的
[根@本地的fcitx]＃让
[根@本地的fcitx]＃make install的
㈣ 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 或者他调用的程序自己崩溃了）。出现这个问题的原因很多。
如果是因为没有找到某些 header 文件，不应该是核心转储错误，而是编译器或者某个过程提示错误信息后退出，他会输出错误信息告诉你问题所在。
至于你编译的这些东西版本都比较老，我建议还是尝试降级整个系统来编译、运行你现在的这些东西。或者升级你这个交叉编译工具链到当前主流的版本来用。
至于交叉工具连当中的 GCC 和你当前本机的 GCC，完全是两个互相独立的 GCC 。
只是他们编译输出的二进制程序针对的指令集不同而已。相对的 binutils 和 glibc 和 kernel-header 都是一样的意思，针对目标而输出的相关程序。当然 glibc 和 kernel-header 主要是以“数据”方式存在，gcc 和 binutils 主要是以可以运行的程序方式存在（当然不是绝对的，比如 gcc 还会提供几个 lib 相关的内容，不过大部分情况下你可以这么理解更直观了解他们的作用）。
一般说来 GCC 是编译器，binutils 是连接器，glibc 是标准 C 库（主要是连接时，连接器必须有目标的函数库文件，也就是 .so 文件，对应 Windows 是 .dll 文件。连接器把函数调用正确的挂接到对应的函数入口上）。linux header 就是 C 语言常见的 C header 文件和相关的开发数据。一般主要用来编译 glibc ，glibc 作为中间层来提供内核相关调用。当然程序有些时候也会直接调用内核函数，这样这些程序在编译时也需要 kernel 的 header 。
这两套东西一个输出你当前 PC 的程序，一个输出 ARM 的程序。两个 GCC 套装之间不能互相替换。只能自己输出属于自己的程序。
但是这两套程序虽然输出的程序不同，但可以运行的部分，却都是在你的计算机上运行。而且你本机的 GCC 因为可以输出本机的程序。所以你需要用他来输出在你本机运行，但是却输出 ARM 程序的 GCC 套装。
这就好比两个锤子，一个锤子用来打铁，一个锤子用来打锡。用途不同，但这两个锤子都是铁做的。
你作这个交叉编译工具链，就是用你手里已经有的打铁的锤子，打出一个用铁制作的用来打锡的锤子。这个打锡的锤子是不能打铁的，同样这个打铁的锤子是不能用来打锡的。
㈥ LINUX交叉编译工具链和GCC是什么关系啊
编译工具链一般最简化的为binutils+gcc+glibc+kernel-header组合的环境。
GCC就是编译器，他的输出每次安装只能有针对一个架构的指令输出。如果要多个架构输出，那就要装多个GCC，所以编译工具链里面会有一个GCC。
交叉编译就是跨架构编译，编译出来的程序不能在本机执行（当然有例外情况）。所以这个时候就需要交叉编译工具链。
工具链光有GCC是不行的，还需要一个binutils的二进制连接器，以及一个最基本的目标架构的C库，C库还需要一个目标架构的内核源代码才能完全工作（当然不是必须的，但编译有的时候需要）
又因为GCC、binutils不能实现单软件同时多架构输出，所以需要单独另装，又加上C库和内核头文件需要目标架构的东西而不能用本机本地架构的数据。
所以一个交叉编译工具链就是针对目标架构准备的单独安装单独使用的binutils+gcc+glibc+kernel-header的集合了。
PS：这个kernel-header并不一定就是Linux，他还可以是别的系统核心开发库，比如FreeBSD。
㈦ 如何使用clang+llvm+binutils+newlib+gdb搭建交叉编译环境
1，Build llvm/clang/lldb/lld 3.5.0等组件
1.0 准备：
至少需要从llvm.org下载llvm, cfe, lldb, compiler-rt,lld等3.5.0版本的代码。
$tar xf llvm-3.5.0.src.tar.gz
$cd llvm-3.5.0.src
$mkdir -p tools/clang
$mkdir -p tools/clang/tools/extra
$mkdir -p tools/lld
$mkdir -p projects/compiler-rt
$tar xf cfe-3.5.0.src.tar.xz -C tools/clang --strip-components=1
$tar xf compiler-rt-3.5.0.src.tar.xz -C projects/compiler-rt --strip-components=1
$tar xf lldb-3.5.0.src.tar.xz -C tools/clang/tools/extra --strip-components=1
$tar xf lld-3.5.0.src.tar.xz -C tools/lld --strip-components=1
1.1 【可选】使用clang --stdlib=libc++时，自动添加-lc++abi。
libc++组件可以使用gcc libstdc++的supc++ ABI，也可以使用c++abi，cxxrt等，实际上自动添加-lc++abi是不必要的，这里这么处理，主要是为了方便起见。实际上完全可以在“clang++ -stdlib=libc++”时再手工添加-lc++abi给链接器。
这里涉及到链接时DSO隐式还是显式的问题，早些时候ld在链接库时会自动引入由库引入的依赖动态库，后来因为这个行为的不可控性，所以ld链接器的行为做了修改，需要显式的写明所有需要链接的动态库，才会有手工添加-lc++abi这种情况出现。
--- llvm-3.0.src/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 18:49:06.663029075 +0800
+++ llvm-3.0.srcn/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 19:36:04.260071355 +0800
@@ -251,6 +251,7 @@
switch (Type) {
case ToolChain::CST_Libcxx:
CmdArgs.push_back("-lc++");
+ CmdArgs.push_back("-lc++abi");
break;
case ToolChain::CST_Libstdcxx:
1.2 【必要】给clang++添加-fnolibgcc开关。
这个开关主要用来控制是否连接到libgcc或者libunwind。
注：libgcc不等于libunwind。libgcc_eh以及supc++的一部分跟libunwind功能相当。
注：libgcc_s和compiler_rt的一部分相当。
这个补丁是必要的， 不会对clang的正常使用造成任何影响 ，只有在使用“-fnolibgcc"参数时才会起作用。
之所以进行了很多unwind的引入，主要是为了避免不必要的符号缺失麻烦，这里的处理相对来说是干净的，通过as-needed规避了不必要的引入。
--- llvm-static-3.5.0.bak/tools/clang/lib/Driver/Tools.cpp 2014-09-10 13:46:02.581543888 +0800
+++ llvm-static-3.5.0/tools/clang/lib/Driver/Tools.cpp 2014-09-10 16:03:37.559019321 +0800
@@ -2060,9 +2060,15 @@
".a");
CmdArgs.push_back(Args.MakeArgString(LibClangRT));
- CmdArgs.push_back("-lgcc_s");
- if (TC.getDriver().CCCIsCXX())
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else {
+ CmdArgs.push_back("-lgcc_s");
+ if (TC.getDriver().CCCIsCXX())
+ CmdArgs.push_back("-lgcc_eh");
+ }
}
static void addProfileRT(
@@ -7150,24 +7156,50 @@
bool isAndroid = Triple.getEnvironment() == llvm::Triple::Android;
bool StaticLibgcc = Args.hasArg(options::OPT_static_libgcc) ||
Args.hasArg(options::OPT_static);
+
+
+
if (!D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
if (StaticLibgcc || isAndroid) {
if (D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
} else {
if (!D.CCCIsCXX())
CmdArgs.push_back("--as-needed");
- CmdArgs.push_back("-lgcc_s");
+ if (Args.hasArg(options::OPT_fnolibgcc))
+ CmdArgs.push_back("-lunwind");
+ else
+ CmdArgs.push_back("-lgcc_s");
if (!D.CCCIsCXX())
CmdArgs.push_back("--no-as-needed");
}
if (StaticLibgcc && !isAndroid)
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc_eh");
else if (!Args.hasArg(options::OPT_shared) && D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
// According to Android ABI, we have to link with libdl if we are
// linking with non-static libgcc.
--- llvm-static-3.5.0.bak/tools/clang/include/clang/Driver/Options.td 2014-08-07 12:51:51.000000000 +0800
+++ llvm-static-3.5.0/tools/clang/include/clang/Driver/Options.td 2014-09-10 13:36:34.598511176 +0800
@@ -788,6 +788,7 @@
def fomit_frame_pointer : Flag<["-"], "fomit-frame-pointer">, Group<f_Group>;
def fopenmp : Flag<["-"], "fopenmp">, Group<f_Group>, Flags<[CC1Option, NoArgumentUnused]>;
def fopenmp_EQ : Joined<["-"], "fopenmp=">, Group<f_Group>, Flags<[CC1Option]>;
+def fnolibgcc : Flag<["-"], "fnolibgcc">, Group<f_Group>, Flags<[CC1Option, NoArgumentUnused]>;
def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, Group<f_Group>;
def foptimize_sibling_calls : Flag<["-"], "foptimize-sibling-calls">, Group<f_Group>;
def force__cpusubtype__ALL : Flag<["-"], "force_cpusubtype_ALL">;
1.3 llvm的其他补丁。
llvm/clang将gcc toolchain的路径hard code在代码中，请查阅tools/clang/lib/Driver/ToolChains.cpp。
找到x86_64-redhat-linux之类的字符串。
如果没有你系统特有的gcc tripple string，请自行添加。
这个tripple string主要是给llvm/clang搜索gcc头文件等使用的，不影响本文要构建的toolchain
1.4 构建clang/llvm/lldb
本文使用ninja。顺便说一下，llvm支持configure和cmake两种构建方式。可能是因为工程太大，这两种构建方式的工程文件都有各种缺陷（主要表现在开关选项上，比如configure有，但是cmake却没有等）。llvm-3.4.1就是因为cmake工程文件的错误而导致了3.4.2版本的发布。
综合而言，cmake+ninja的方式是目前最快的构建方式之一，可以将构建时间缩短一半以上。
mkdir build
cd build
cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE="Release" \
-DCMAKE_CXX_FLAGS="-std=c++11" \
-DBUILD_SHARED_LIBS=OFF \
-DLLVM_ENABLE_PIC=ON \
-DLLVM_TARGETS_TO_BUILD="all" \
-DCLANG_VENDOR="MyOS" ..
ninja
ninja install
如果系统原来就有clang/clang++的可用版本，可以添加：
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
这样就会使用系统的clang++来构建llvm/clang
2，测试clang/clang++。
自己找几个简单的c/cpp/objc等编译测试一下即可。完整测试可以在构建时作ninja check-all
3，libunwind/libc++/libc++abi，一套不依赖libgcc, libstdc++的c++运行库。
3.1 从https://github.com/pathscale/libunwind 获取代码。
libunwind有很多个实现，比如gnu的libunwind, path64的libunwind，还有libcxxabi自带的Unwinder.
这里作下说明：
1)，gnu的libunwind会有符号缺失和冲突。
2)，libcxxabi自带的Unwinder是给mac和ios用的，也就是只能在darwin体系构建。目前Linux的实现仍然不全，等linux实现完整了或许就不再需要path64的unwind实现了。
暂时建议使用pathscale的unwind实现。
mkdir -p build
cd build
cmake -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="-m64" ..
ninja
mkdir -p /usr/lib
cp src/libunwind.so /usr/lib
cp src/libunwind.a /usr/lib
3.2 第一次构建libcxx.
必须先构建一次libcxx，以便后面构建libcxxabi。这里构建的libcxx实际上是使用gcc的libgcc/stdc++/supc++的。
打上这个补丁来禁止libgcc的引入：
diff -Nur libcxx/cmake/config-ix.cmake libcxxn/cmake/config-ix.cmake
--- libcxx/cmake/config-ix.cmake 2014-06-25 06:57:50.000000000 +0800
+++ libcxxn/cmake/config-ix.cmake 2014-06-25 09:05:24.980350544 +0800
@@ -28,5 +28,4 @@
check_library_exists(c printf "" LIBCXX_HAS_C_LIB)
check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
-check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
编译安装：
mkdir build
cd build
cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
..
ninja
ninja install
3.3，测试第一次构建的libcxx。
使用"clang++ -stdlib=libc++ -o test test.cpp -lstdc++"编译简单c++代码，检查是否出错。(如果前面构建clang是已经apply了c++abi的链接补丁，这里会出现找不到c++abi的情况，跳过即可)
使用"ldd test"查看test二进制动态库使用情况。可以发现，test依赖于libgcc_s/libc++/libstdc++。（多少有些不爽了吧？使用了libc++居然还要依赖libstdc++？）