gdb交叉编译
① 在linux（Ubuntu）下用crosstool-ng编译交叉编译工具链，编译到native gdb时，出错了，求解！
问题解决了吗？
我也有同样的问题！
② 如何使用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++？）
③ ecplise和GDB有啥区别想学linux嵌入式，可是被各种各样的软件搞晕了！ecplise、GDB、GCC。。
eclipse是开发java的 也有C++（好像是），gdb是调试软件。gcc是编译软件。arm-linux-gcc是交叉编译器，就是说在电脑上编译，但是只在arm上运行。arm-linux-gcc在linux环境必须安装
④ 建立linux交叉编译环境的步骤
什么交叉编译环境？
arm？mips？ppc？
初学可以看看friendlyarm提供的说明书，里面讲到fedora上建立交叉编译环境，redhat上也一样的
http://www.arm123.com.cn/mini2440/mini2440-um-20090514.rar
⑤ linux gdb 交叉编译是什么
一般用于嵌入式开发中。
由于嵌入式环境中的CPU/内存都很小，不能用于编译。PC机的性能都很好，编译起来也很快。
交叉编译的意思就是，在PC上编译，编译出来的程序在嵌入式机器上运行。
⑥ gcc -arm这个交叉编译工具。有没有可以再window上使用的
yagarto和codesourcery都是在windows下用的，官方已经编译打包好的EXE文件
cygwin下可以自己编译源代码，做出GNU工具链
mingw也可以实现
还有一些在windows下用的IDE，专门针对GNU工具链的，code::blocks,emide等
我在用emIDE,arm-none-eabi-gdb调试ARM
⑦ arm-linux 交叉编译环境的建立，希望有清楚的人解答，复制的闪人
是这样子的，计算机linux中原有的gcc是针对通用的X86等处理器而言的，编译出来的可执行文件是只能在通用计算机上运行的，arm也是一种处理器，只不过其指令等和X86等CPU不同，所以需要有针对arm的编译器来编译源程序，才能在arm中运行。
我在arm9下做过linux，qt编程，需要先在PC上安装linux，然后安装arm-linux-gcc，同时为了可以使用arm-linux-gcc来编译程序，需要指定环境变量，这个可以在.profile等文件中进行更改，具体办法你查一下就知道了。或者使用export命令在终端中设置环境变量。两种方法的结果有区别哦！
你想用2440的开发板的话就是arm9了，我还没找到arm9的仿真工具，但是网上已经有arm7的仿真工具。
对于arm-linux-gcc，只要你安装好并设置好了路径（环境变量）后，在一个终端中输入#arm-linux-gcc -v
那么你一般可以看到你安装的arm-linux-gcc 版本信息，到此你就可以使用它编译你的源程序，然后将生成的可执行文件下载到arm开发板中就可以运行了。
还有什么问题再说吧，我也是一个人摸索出来的，估计摸索了一个月才成功的在arm上运行了第一个自己的qt图形界面程序，祝你好运！
我的建议：
一、熟悉linux 的各种操作命令（如export）
二、学会怎么下载可执行文件到arm中
三、学会用pc控制arm上的linux
我只用过arm-linux-gcc，在你的安装文件夹下可以找到
⑧ 如何编译可以在Windows下运行的带有python支持的ARM Linux GDB
距离上次我编译这种GDB的时间转眼过了3年，现在（2017年3月6日），Linaro编译器已经支持python了。不过，当我们自己使用的时候还是有一些麻烦的，因为Linaro编译器的sysroot和平时我们用的sysroot还是不一样的，需要在gdbinit文件里面用"set sysroot"或"set solib-search-path"之类设定路径。生在狮子座长成座的我，是无法容忍这种麻烦的，所以还是自己来弄一次。
还是在Linux下做MinGW的交叉编译，需要MinGW交叉编译器。
因为Linaro已经做了很多事情了，源码，expat，python都搞定了，资源如下：
Linaro GDB git：
从这上面找到与Linaro编译器版本对应的源码
编译用的expat和python：
编译的时候只需要设定一个环境变量：
export PYTHON_MINGW=/home/c/gdb-arm/python-2.7.4-mingw32
然后配置一下就行了：
./configure --host=i586-mingw32msvc --target=arm-linux-gnueabihf --with-libexpat-prefix=/home/c/gdb-arm/expat-2.1.0-1 --without-libunwind-ia64 --without-libunwind-ia64 --without-lzma --with-python=/home/c/gdb-arm/python-2.7.4-mingw32 --without-guile --without-babeltrace --with-sysroot=/opt/sysroot-arm
然后就可以：
make
make DESTDIR= install
⑨ ubuntu安装arm linux 交叉工具链包含gdb吗
安装步骤
1、将压缩包arm-linux-gcc-4.4.3.tar.gz存放在一个目录下，这个目录就是你等会解压缩的目录，以后这个目录就不能随便删掉了
2、使用tar命令：tar zxvf arm-gcc-4.4.3.tar.gz将software文件夹下的arm-linux-gcc-4.4.3.tar.gz解压缩安装到当前目录下如下图
通过下图可以看到解压成功了，并且解压后的文件存放了/home/song/software/opt/FriendlyARM/toolschain/4.4.3文件夹下，如下图所示，这个存放路径可得记住，如下图
3、接下来配置系统环境变量，把交叉编译工具链的路径添加到环境变量PATH中去，这样就可以在任何目录下使用这些工具。记下上一步中的安装路径，使用命令：vim /etc/profile 编辑profile文件，添加环境变量。
在profile中最后一行添加： export PATH=$PATH:/home/song/software/opt/FriendlyARM/toolschain/4.4.3/bin 这个路径就是那个bin目录所在的路径，可能你的不一样，按照你实际的目录填就可以了
⑩ cygwin 中如何安装arm-linux-gcc交叉编译器
交叉编译工具链作为嵌入式Linux开发的基础，直接影响到嵌入式开发的项目进度和完成质量。由于目前大多数开发人员使用Windows作为嵌入式开发的宿主机，在Windows中通过安装VMware等虚拟机软件来进行嵌入式Linux开发，这样对宿主机的性能要求极高。Cygwin直接作为Windows下的软件完全能满足嵌入式Linux的开发工作，对硬件的要求低及方便快捷的特点成为嵌入式开发的最佳选择。
目前网络上Cygwin下直接可用的交叉编译器寥寥无几且版本都比较低，不能满足开源软件对编译器版本依赖性的要求(如低版本工具链编译U-Boot出现软浮点问题等);Crosstool等交叉工具链制作工具也是更新跟不上自由软件版本的进度;同时系统介绍Cygwin下制作交叉编译器方面的资料很少。针对上述情况，基于最新版gcc等自由软件构建Cygwin下的交叉编译器显得尤为迫切和重要。
构建前准备工作
首先Cygwin下必须保证基本工具比如make}gcc等来构建bootstrap-gcc编译器，这可以在安装Cygwin时选择安装。参照gcc等安装说明文档来在Cygwin下查看是否已经安装，如输入gcc --v等。
源码下载
gcc-4.5.0的编译需mpc的支持，而mpc又依赖gmp和mpfr库。从各个项目官方网站上下载的最新的源码:
binutils-2.20. l .tar.bz2
gmp-S.O. l .tar.bz2
mpc-0.8.2.tar.gz
mpfr-3.O.O.tar.bz2
gcc-4.S.O.tar.bz2
linux-2.6.34.tar.bz2
glibc-2.11.2.tar.bz2
glibc-ports-2. l l .tar.bz2
gdb-7. l.tar.bz2
设置环境变量
HOST:工具链要运行的目标机器;BUILD:用来建立工具链的机器;TARGET工具链编译产生的二进制代码可以运行的机器。
BUILD=i686-pc-cygwin
HOST=i686-pc-cygwin TARGET=arm-linux
SYSROOT指定根目录，$PREFIX指定安装目录。目标系统的头文件、库文件、运行时对象都将被限定在其中，这在交叉编译中有时很重要，可以防止使用宿主机的头文件和库文件。本文首选$SYSROOT为安装目录，$PREFIX主要作为glibc库安装目录。
SYSROOT=/cross-root
PREFIX=/cross-root/arm-linux
由于GCC-4.5.0需要mpfr,gmp,mpc的支持，而这三个库又不需要交叉编译，仅仅是在编译交叉编译链时使用，所以放在一个临时的目录。
TEMP_PREFIX=/build-temp
控制某些程序的本地化的环境变量:
LC ALL=POSIX
设置环境变量:
PATH=$SYSROOT/bin:儿in:/usr/bin
设置编译时的线程数f31减少编译时间:
PROCS=2
定义各个软件版本:
BINUTILS V=2.20.1
GCC V=4.5.0
GMP V=5.0.1
MPFR V=3.0.0
MPC V二0.8.2
LINUX V二2.6.34
GLIBC V=2.11.2
GLIBC-PORTS V=2.11
GDB V=7.1
构建过程详解
鉴于手工编译费时费力，统一把构建过程写到Makefile脚本文件中，把其同源码包放在同一目录下，执行make或顺次执行每个命令即可进行无人值守的编译安装交叉工具
链。以下主要以Makefile执行过程为主线进行讲解。
执行“make”命令实现全速运行
可在Cygwin的Shell环境下执行“make>make.log 2>&1”命令把编译过程及出现的错误都输出到make.log中，便于查找:
all:prerequest install-deps install-cross-stage-one install-
cross-stage-two
预处理操作
"make prerequest'，命令实现单步执行的第一步，实现输出变量、建立目录及解压源码包等操作。0'set十h”关闭bash的Hash功能，使要运行程序的时候，shell将总是搜索PATH里的目录[4]。这样新工具一旦编译好，shell就可以在$(SYSROOT)/bin目录里找到: prerequest:
set +h&&mkdir -p $(SYSROOT)/bin&&
mkdir -p $(PREFIX)/include&&
mkdir -p $(TEMP一REFIX)&&
export PATH LCes ALL&&
tar -xvf gmp-$(GMP_V).tar.bz2&&
tar -xvf mpfr-$(MPFR_V).tar.bz2&&
tar -xvf mpc-$(MPC_V).tar.gz&&
tar -xvf binutils-$(BINUTILS_V).tar.bz2&&
tar -xvf gcc-$(GCC_V).tar.bz2&&
tar -xvf linux-$(LINUX_V).tar.bz2&&
tar -xvf glibc-$(GLIBC_V).tar.bz2&&
tar -xvf glibc-ports-$(GLIBC-PORTS_V).tar.bz2&&
my glibc-ports-$(GLIBC-PORTS_V)
glibc-$(GLIBC_V)/ports&&
tar -xvf gdb-$(GDB V).tar.bz2
非交叉编译安装gcc支持包mpc
00make install-deps”命令实现单步执行的第二步，实现mpc本地编译，mpc依赖于gmp和mpfr
install-deps:gmp mpfr mpc
gmp:gmp-$(GMP_V)
mkdir -p build/gmp&&cd build/gmp&&
../../gmp-*/configure
--disable-shared --prefix=$(TEMP_PREFIX)&&
$(MAKE)一$(PROCS)&&$(MAKE) install
mpfr:mpfr-$(MPFR_V)
mkdir -p b-uild/mpfr&&cd build/mpfr&&
../..//mpfr-*/configure
LDF'LAGS="-Wl,-search_paths_first”--disable-shared
--with-gmp=$(TEMP_PREFIX)
--prefix=$(TEMP_PREFIX)&&
$(MAKE)一$(PROCS) all&&$(MAKE) install
mpc: mpc-$(MPC_V) gmp mpfr
mkdir -p build/mpc&&cd build/mpc&&
../../mpc-*/configure
--with-mpfr=$(TEMP PREFIX)
--with-gmp=$(TEMP_PREFIX)
--prefix=$(TEMP_PREFIX)&&
$(MAKE)一$(PROCS)&&$(MAKE) install
交叉编译第一阶段
"make install-cross-stage-one'，命令实现单步执行的第三步，编译安装binutils,bootstrap-gcc和获取Linux内核头文件:
install-cross-stage-one:cross-binutils cross-gcc get-kernel-headers
编译安装binutils
cross-binutils: binutils-$(BINUTILS_ V)
mkdir -p build/binutils&&cd build/binutils&&
../..//binutils-*/configure --prefix=$(SYSROOT)
--target=$(TARGET)--disable-nls&&
$(MAKE)j$(PROCS)&&$(MAKE) install
编译安装bootstrap-gcc。使用一disable-shared参数的意思是不编译和安装libgcc_ eh.a文件。glibc软件包依赖这个库，因为它使用其内部的一lgcc_eh来创建系统[6]。这种依赖
性，可通过建立一个指向libgcc.a符号链接得到满足，因为该文件最终将含有通常在libgcc- eh.a中的对象(也可通过补丁文件实现)。
cross-gcc:gcc-$(GCC_V)
mkdir -p build/gcc&&cd build/gcc&&
二//gcc-*/configure
--target=$(TARGET)--prefix=$(SYSROOT)
--disable-nls --disable-shared --disable-multilib
--disable-decimal-float--disable-threads
--disable-libmudflap --disable-libssp
--disable-libgomp --enable-languages=c
--with-gmp=$(TEMP_PREFIX)
--with-mpfr=$(TEMP_PREFIX)
--with-mpc=$(TEMP_PREFIX)&&
$(MAKE) -j$(PROCS)&&$(MAICE) install&&
In -vs libgcc.a'arm-linux-gcc -print-libgcc-file-name I
sed's/libgcc/& eh/'}
获取Linux内核头文件:
get-kernel-headersainux-$(LINUX_V)
cd linux-$(LINUX_V)&&
$(MAICE) mrproper&&$(MAKE) headers check&&
$(MAKE) ARCH=arm&&
INSTALLes HDR_ PATH=dest headers_ install&&
find dest/include
(-name .install一。-name ..installNaNd)-delete&&
cp -rv desdinclude/* $(PREFIX)/include
交叉编译第二阶段
编译安装glibc、重新编译安装binutils、完整编译安装gcc和编译安装gdb o "make install-cross-stage-two'，命令实现单步执行的第四步: install-cross-stage-two:cross-glibc cross-rebinutils cross-g++ cross-gdb
编译安装glibca glib。的安装路径特意选为$(PREFIX)，与gcc更好找到动态链接库也有关系，选在$(SYSROOT)提示找不到crti.o; glibc已经不再支持i386; glibc对ARM等的处理器的支持主要通过glibc-ports包来实现;正确认识大小写敏感(Case Sensitive)和大小写不敏感(CaseInsensitive)系统，大小写敏感问题主要影响到glibc，是交叉编译glibc成功的关键:Cygwin帮助手册中可知Cygwin是默认大小写不敏感的n}，但是UNIX系统是大小写敏感的，这也是Cygwin和UNIX类系统的一个区别。通过作者自行参考制作的glibc-2.11.2-cygwin.patch补T使glibc变为Case-Insensitive，此补丁主要是对大小写敏感问题改名来实现。
交叉编译过程中安装的链接器，在安装完Glibc以前都无法使用。也就是说这个配置的forced unwind支持测试会失败，因为它依赖运行中的链接器。设置libc_ cvforced unwind=yes这个选项是为了通知configure支持force-unwind，而不需要进行测试。libc cv_c_cleanup=yes类似的，在configure脚本中使用libc_cv_c cleanup=yes，以便配置成跳过测试而支持C语言清理处理。
cross-glibc:glibc-$(GLIBC_V)
cd glibc-$(GLIBC_V)&&
patch -Np 1 –i...//glibc-2.11.2-cygwin.patch&&
cd..&&mkdir -p build/glibc&&
cd build/glibc&&
echo"libc cv_forcedes unwind=yes">config.cache&&
echo "libc cv_c_cleanup=yes">>config.cache&&
echo "libc cv_arm_tls=yes">>config.cache&&
../../glibc-*/configure --host=$(TARGET)
--build=$(../OneScheme/glibc-2.11.2/scripts/config.guess)
--prefix=$(PREFIX)--disable-profile
--enable-add-ons --enable-kernel=2.6.22.5
--with-headers=$(PREFIX)/include
--cache-file=config.cache&&
$(MAKE)&&$(MAKE) install
重新编译安装binutils。编译之前要调整工具链，使其
指向新生成的动态连接器。
调整工具链:
SPECS=
'dirname $(arm-linux-gcc -print-libgcc-file-name)'/specs
arm-linux-gcc -mpspecs
sed -e 's@/lib(64)\?/ld@$(PREFTX)&@g' -e ,}/}}*cPP}$/{n;s,$，-isystem $(PREFIX)/include,}"
>$SPECS
echo "New specs file is: $SPECS"
unset SPECS
测试调整后工具链:
echo 'main(川’>mmy.c
arm-linux-gcc
-B/cross-root/arm-linux/lib mmy.c
readelf -1 a.out I grep’:/cross-roobarm-linux'
调整正确的输出结果:
[Requesting program interpreter: /tools/lib/ld-linux.so.2j
一切正确后删除测试程序:
rm -v mmy.c a.out
重新编译binutils。指定--host,--build及--target，否则配置不成功，其config.guess识别能力不如gcc做的好。
cross-rebinutils: binutils-$(BINUTILS_V)
mkdir -p build/rebinutils&&
cd build/rebinutils&&CC="$(TARGET)-gcc
-B/cross-roodarm-linux/lib/"&&AR=$(TARGET)-ar&&
RANLIB=$(TARGET)-ranlib&&../..//binutils-*/configure
--host=$(HOST)--build=$(BUILD)--target=$(TARGET)
--prefix=$(SYSROOT)--disable-nls
--with-lib-path=$(PREFIX)/lib&&
$(MAKE)--$(PROCS)&&$(MAKE) install
高于4.3版的gcc把这个编译当作一个重置的编译器，并且禁止在被一prefix指定的位置搜索startfiles。因为这次不是重置的编译器，并且$(SYSROOT)目录中的startfiles对于创
建一个链接到$$(SYSROOT)目录库的工作编译器很重要，所以我们使用下面的补丁，它可以部分还原gcc的老功能tai . patch -Npl –i../gcc-4.5.0-startfiles_fix-l.patch
在正常条件下，运行gcc的fixincludes脚本，是为了修复可能损坏的头文件。它会把宿主系统中已修复的头文件安装到gcc专属头文件目录里，通过执行下面的命令，可以抑
制fixincludes脚本的运行[9](此时目录为/gcc-4.5.0)。
cp -v gcc/Makefile.in{,.orig}
sed 's@\./fixinc\.sh@-c true@'
gcc/Makefile.in.orig > gcc/Makefile.in
下面更改gcc的默认动态链接器的位置，使用已安装在/cross-root/ann-linux目录下的链接器，这样确保在gcc真实的编译过程中使用新的动态链接器。即在编译过程中创建的所有
二进制文件，都会链接到新的glibc文件
for file in
$(find gcc/config -name linux64.h-o -name linux.h –o -name sysv4.h)
do cp -uv $file{,.orig}
sed -a 's@/lib(64)?(32)?/Id@/cross-root/arm-linux&@g’-e's@/usr@/cross-rootlarm-linux@g' $file.orig>$file echo‘
#undef STANDARD INCLUDE DIR
#define STANDARD_ INCLUDE DIR "/cross-root/arm-linux/include"
#define STANDARD STARTFILE PREFIX 1 "/cross-root/arm-linux/lib"
#define STANDARD_ STARTFILE_ PREFIX_ 2””’>>$file
touch $file.orig done
完整编译安装gcc。最好通过指定--libexecdir更改libexecdir到atm-linux目录下。--with-local-prefix选项指定gcc本地包含文件的安装路径此处设为$$(PREFIX)，安装后就会在内核头文件的路径下。路径前指定$(Pwd)则以当前路径为基点，不指定则默认以/home路径为基点，这点要注意。
cross-g++:gcc-$(GCC-)
mkdir -p build/g十+&&cd build/g++&&
CC="$(TARGET)-gcc AR=$(TARGET)-ar&&
-B/cross-roodarm-linux/lib/"&&
RANLIB=$(TARGET)-ranlib&&
..//gcc-*/configure
--host=$(HOST)--build=$(BUILD)--target=$(TARGET)
--prefix=$(SYSROOT)--with-local-prefix=$(PREFIX)
--enable-clocale=gnu --enable-shared
--enable-threads=posix --enable -cxa_atexit
--enable-languages=c,c++--enable-c99
--enable-long-long --disable-libstdcxx-pch
--disable-libunwind-exceptions
--with-gmp=$(TEMP_PREFIX)
--with-mpfr=$(TEMP_PREFIX)
--with-mpc=$(TEMP_PREFIX)&&
$(MAKE) LD_IBRARY_ATH=
$(pwd)/$(../../gcc-4.5.0/config.guess)/libgcc&&
$(MAKE) install
编译安装gdb，至此完成整个工具链的制作。
cross-gdb: gdb-$(GDB V)
mkdir -p build/gdb&&cd build/gdb&&
../../gdb-*/configure --prefix=$(SYSROOT)
--target=$(TARGET)--disable-werror&&
$(MAKE)-j$(PROCS)&&$(MAKE) install
“make clean”命令清除编译生成的文件和创建解压的文件夹
.PHONY:clean
dean:
rm -fr $(TEMP_PREFIX) build
binutils-$(BINUTIL,S_V) gcc-$(GCC_V)
glibc-$(NEWL.IB_V) gdb-$(GDB_V)
gmp-$(GMP_V) mpc-$(MPC_V) mpfr-$(MPFR_V)
工具链测试
命令行中输入以下内容:
echo 'main(){}’>mmy.c
arm-linux-gcc -o mmy.exe mmy.c
file mmy.exe
运行正常的结果:
mmy.exe: ELF 32-bit LSB executable, ARM, version 1,for GNU/Linux 2.6.22, dynamically linked (uses shared libs),not stripped.