偏执的需求--编译Android Toolchain--的可参考文章

arm-linux工具链制作

http://blog.163.com/xu_jin_rong/blog/static/1491966220083111148818/

一、交叉编译环境介绍

交叉编译是嵌入式开发过程中的一项重要技术，其主要特征是某机器中执行的程序代码不是在本机编译生成，而是由另一台机器编译生成，一般把前者称为目标机，后者称为主机。

采用交叉编译的主要原因在于，多数嵌入式目标系统不能提供足够的资源供编译过程使用，因而只好将编译工程转移到高性能的主机中进行，这就需要在强大的pc机上建立一个用于目标机的交叉编译环境。这是一个由编译器、连接器和解释器组成的综合开发环境。

linux下的交叉编译环境重要包括以下几个部分：

     1，针对目标系统的编译器gcc；

     2，针对目标系统的二进制工具binutils；

     3，目标系统的标准c库glibc，有时出于减小libc库大小的考虑，你也可以用别的c库来代替glibc，例如uClibc、newlib等；

     4，目标系统的linux内核头文件。

二、准备工作

本文实验所使用的主机环境为cygwin，所以在编译交叉工具链的时候要注意cygwin版本的问题，建议将cygwin在线升级至最新版本，本文试验中cygwin DLL版本号为1.5.21。

因为gcc、binutils、glibc以及linux内核头文件均有各自的版本号，并不是任意组合都可以编译成功并最终建立一个交叉编译环境的。一些可以直接利用的组合方式，可以通过该网址查看：http://kegel.com/crosstool/crosstool-0.42/buildlogs/当我们选择了某一种组合以后，仍然需要对源代码做相应的修改，才能最终编译成功。

本文使用的组合为gcc-3.4.5+glibc-2.2.5+binutils-2.15+linux-2.6.8(头文件)，因为本文建立的交叉编译环境是用来编译linux-2.6系列内核，以及运行在该系列内核上的程序，故选择了linux-2.6.8内核的头文件，当然也可以选择其他合适的linux-2.6版本的内核。

针对上面的这种组合，我们还需要打相应的补丁，这些补丁可以通过如下网址下载到：http://kegel.com/crosstool/crosstool-0.42.tar.gz解压后在patch文件夹中可以找到相应的补丁。下面给出一些下载的链接，便于下载。

三、交叉编译环境的建立过程

为了更清晰的描述交叉环境的建立过程，在此对各个源码包的作用进行说明。

binutils-2.15.tar.bz2：这个压缩包包含有ld,ar,as等一些产生或者处理二进制文件的工具。其主要目的是为GNU系统提供汇编和连接工具等。

gcc-3.4.5.tar.bz2：这个压缩包主要是为GNU系统提供C编译器。现在支持多种语言，这其中包括C/C++、Fortran、Java、Objective-C、Ada等。

glibc-2.2.5.tar.gz：Libc是很多用户层应用都要用到的库，用于定义系统调用和其它一些基本的函数调用。

glibc-linuxthreads-2.2.5.tar.gz：这是Libc用于支持Posix线程而单独发布的一个压缩包。

linux-2.6.8.tar.bz2：这个压缩包就是Linux的内核，在编译glibc时，要用到Linux内核中的include目录的内核头文件。

交叉编译环境建立过程如下，同时图3-1也清晰地描述了此过程。

（1）创建编译环境。在这个过程中，将设置一些环境变量，创建安装目录，安装内核源代码和头文件等。

（2）建立内核头文件，主要是生成include/linux/version.h和 include/linux/autoconf.h文件，这是编译 glibc 是要用到的，version.h 和 autoconf.h 文件的存在，也说明了你生成了正确的头文件。

（3）创建binutils。这个过程结束后，会创建类似arm-linux-ld等工具。binutils是一组开发工具，包括链接器、汇编器以及其他用于目标文件和档案的工具.首先安装软件包binutils是非常重要的，因为glibc和gcc会针对可用的连接器和汇编器进行多种测试，以决定打开某些特性。

（4）创建一个交叉编译版本的gcc（称为bootstrap gcc）。注意：在这个过程中只能编译C程序，而不能编译C++程序。创建一个完整的交叉编译版本gcc，需要交叉编译版本的glibc及其头文件，而交叉编译版本的glibc是通过交叉编译版本的gcc创建的。面对这个先有鸡还是先有蛋的问题，解决办法是先编译仅支持C语言的bootstrap gcc编译器，并禁止支持线程。

（5）创建一个交叉编译版本的glibc。这里最容易出现问题。glibc是一个提供系统调用和基本函数的C语言库，比如open,malloc和printf等，所有动态链接的程序都要用到它。创建glibc需要的时间很长。

（6）重新创建gcc（称为full gcc）。因为前面创建gcc的过程没有编译C++编译器，现在glibc已经准备好了，所以这个步骤将产生一个更完整的full gcc编译器。

图3-1交叉编译环境建立过程

四、交叉环境的建立

4．1工作目录及环境变量的设置

因为项目空间中目录众多, 我们可以通过export命令设置一些环境变量以方便后面的工作，见表4-1。目录结构如图4-1所示。

图4-1 目录结构图

4．2、建立内核头文件

因为交叉工具链工具链是针对特定的处理器和操作系统的，因此在编译之前就需要对linux内核进行配制，可以通过“make config”或“make menuconfig”命令对内核进行配制，配制完成后，在linux源文件的目录下就会生成一个.config文件，这就是我们所需要的文件。如果你有现成的配制文件，可以在“make menuconfig”中加载进来，或者使用cp命令把配制文件复制到linux源文件目录下并改名为.config。

此时的.config还不是完整的，因为有些信息在配置文件中没有给出，需要用户通过控制台输入，可以使用“make ARCH=arm oldconfig”命令，该命令可以使内核设置进程读取用户已有的设置信息，从而提示用户输入某一内核设置变量的值,这一变量在已有的内核设置文件中是找不到的,此处ARCH=arm就是我们输入的值。

接下来执行如下命令产生相关文件和链接：

make ARCH=$ARCH include/asm include/linux/version.h include/asm-$ARCH/.arch

执行完后，在linux2.6.8/include目录下生成version.h和autoconfig.h。这两个文件，在编译glibc时会用到。至此，linux的头文件已经生成完毕，现在通过如下命令，将编译交叉工具链时用到的头文件拷贝到$HEADERDIR目录下。图4-2为目录结构图。

cp -r include/asm-generic $HEADERDIR/asm-generic

cp -r include/linux $HEADERDIR

cp -r include/asm-${ARCH} $HEADERDIR/asm

 图4-2 linux内核头文件目录结构

4．3、建立二进制工具（binutils）

首先安装二进制工具链，使用主机的gcc进行编译。生成的交叉二进制工具arm-linux-ar,arm-linux-as,arm-linux-ld等是编译其他交叉程序的基础，所以必须放到第一步进行。编译过程如下：

cd $BUILD_DIR

mkdir -p build-binutils;

cd build-binutils

${BINUTILS_DIR}/configure --target=$TARGET --host=$GCC_HOST --prefix=$PREFIX --disable-nls --with-sysroot=$SYSROOT

make all

make install

export PATH="$PREFIX/bin:$PATH"

binutils工具生成以后，要将其路径加入环境变量PATH中，以便在后续编译过程中能够找到它们。生成的工具如图4-3所示。

图4-3生成的binutils工具

4．4、建立初始编译器（bootstrap gcc）

为了生成交叉编译版的glibc，我们就必须创建一个交叉编译版本的gcc。但是在资源有限的条件下，不可能拥有一个完整的交叉编译版的gcc（因为编译完整的gcc是需要交叉编译版的glibc及其头文件，而现在还没有）。我们现在只能够先利用主机的gcc编译出一个简单的交叉编译版gcc，即arm-linux-gcc及相关工具。arm-linux-gcc只能编译C程序，而不能编译C++程序。编译过程如下所示。

${GCC_CORE_DIR}/configure --target=$TARGET --host=$GCC_HOST \

--prefix=$CORE_PREFIX \

        --with-local-prefix=$SYSROOT \

        --disable-multilib \

        --with-newlib \

        --disable-nls \

        --enable-threads=no \

        --enable-symvers=gnu \

        --enable-__cxa_atexit \

        --enable-languages=c \

        --disable-shared

make all-gcc

make install-gcc

export PATH="$CORE_PREFIX/bin:${PATH}"

bootstrap gcc生成以后，要将其路径加入环境变量PATH中，以便在后续编译过程中能够找到它们。生成的工具如图4-4所示。

图4-4生成bootstrap gcc后的目录结构图

4．5、建立c库(glibc)

glibc是一个提供系统调用和基本函数的C语言库，比如open, malloc和printf等，所有动态链接的程序都要用到它，这里最容易出现问题，并且创建glibc需要的时间很长。这时候编译器将会使用上一步生成的arm-linux-gcc，同时会用到一开始准备的linux内核头文件。编译glibc的命令如下所示。

BUILD_CC=gcc CFLAGS="-O -fno-unit-at-a-time" CC="${TARGET}-gcc

       AR=${TARGET}-ar RANLIB=${TARGET}-ranlib \

        ${GLIBC_DIR}/configure --prefix=/usr \

        --build=$BUILD --host=$TARGET \

        --without-cvs --disable-profile --disable-debug --without-gd \

        --enable-shared \

        --enable-add-ons=linuxthreads --with-headers=$HEADERDIR

make LD=${TARGET}-ld RANLIB=${TARGET}-ranlib all

make install_root=${SYSROOT} install

4．6、建立全套编译器（full gcc）

因为前面创建gcc的过程没有编译C++编译器，现在glibc已经准备好了，所以这个步骤将产生一个更完整的full gcc编译器,命令如下所示。

${GCC_DIR}/configure --target=$TARGET --host=$GCC_HOST --prefix=$PREFIX \

        --with-local-prefix=${SYSROOT} \

        --disable-nls \

        --enable-threads=posix \

        --enable-symvers=gnu \

        --enable-__cxa_atexit \

        --enable-languages= c,c++ \

        --enable-shared \

        --enable-c99 \

        --enable-long-long

make all

make install

至此，已经生成一个完整的交叉编译版gcc，此时生成的arm-linux-gcc等工具和4.3节生成的arm-linux-gcc并不相同，完整的交叉编译版的gcc被添加至$PREFIX/bin目录，其结构如图4-5所示。

 

图4-5生成full gcc后的目录结构图

如何为嵌入式开发建立交叉编译环境

https://www.ibm.com/developerworks/cn/linux/l-embcmpl/

梁元恩  (sunix_yuanenliang@yahoo.com.cn), 软件工程师

梁元恩,软件工程师，研究兴趣主要是操作系统，图形学等。您可以通过sunix_yuanenliang@yahoo.com.cn联系他。

简介： 在进行嵌入式开发之前，首先要建立一个交叉编译环境，这是一套编译器、连接器和libc库等组成的开发环境。文章通过一个具体的例子说明了这些嵌入式交叉编译开发工具的制作过程

随着消费类电子产品的大量开发和应用和Linux操作系统的不断健壮和强大，嵌入式系统越来越多的进入人们的生活之中，应用范围越来越广。

在裁减和定制Linux，运用于你的嵌入式系统之前，由于一般嵌入式开发系统存储大小有限，通常你都要在你的强大的pc机上建立一个用于目标机的交叉编译环境。这是一个由编译器、连接器和解释器组成的综合开发环境。交叉编译工具主要由 binutils、gcc 和 glibc 几个部分组成。有时出于减小 libc 库大小的考虑，你也可以用别的 c 库来代替 glibc，例如 uClibc、dietlibc 和 newlib。建立一个交叉编译工具链是一个相当复杂的过程，如果你不想自己经历复杂的编译过程，网上有一些编译好的可用的交叉编译工具链可以下载。

下面我们将以建立针对arm的交叉编译开发环境为例来解说整个过程，其他的体系结构与这个相类似，只要作一些对应的改动。我的开发环境是，宿主机 i386-redhat-7.2，目标机 arm。

这个过程如下

1. 下载源文件、补丁和建立编译的目录

2. 建立内核头文件

3. 建立二进制工具（binutils）

4. 建立初始编译器（bootstrap gcc）

5. 建立c库(glibc)

6. 建立全套编译器（full gcc）

下载源文件、补丁和建立编译的目录

1. 选定软件版本号

选择软件版本号时，先看看glibc源代码中的INSTALL文件。那里列举了该版本的glibc编译时所需的binutils 和gcc的版本号。例如在 glibc-2.2.3/INSTALL 文件中推荐 gcc 用 2.95以上，binutils 用 2.10.1 以上版本。

我选的各个软件的版本是：

linux-2.4.21+rmk2
binutils-2.10.1
gcc-2.95.3
glibc-2.2.3
glibc-linuxthreads-2.2.3

如果你选的glibc的版本号低于2.2，你还要下载一个叫glibc-crypt的文件，例如glibc-crypt-2.1.tar.gz。 Linux 内核你可以从www.kernel.org 或它的镜像下载。

Binutils、gcc和glibc你可以从FSF的FTP站点ftp://ftp.gun.org/gnu/ 或它的镜像去下载。在编译glibc时，要用到 Linux 内核中的 include 目录的内核头文件。如果你发现有变量没有定义而导致编译失败，你就改变你的内核版本号。例如我开始用linux-2.4.25+vrs2，编译glibc-2.2.3 时报 BUS_ISA 没定义，后来发现在 2.4.23 开始它的名字被改为 CTL_BUS_ISA。如果你没有完全的把握保证你改的内核改完全了，就不要动内核，而是把你的 Linux 内核的版本号降低或升高，来适应 glibc。

Gcc 的版本号，推荐用 gcc-2.95 以上的。太老的版本编译可能会出问题。Gcc-2.95.3 是一个比较稳定的版本，也是内核开发人员推荐用的一个 gcc 版本。

如果你发现无法编译过去，有可能是你选用的软件中有的加入了一些新的特性而其他所选软件不支持的原因，就相应降低该软件的版本号。例如我开始用 gcc-3.3.2，发现编译不过，报 as、ld 等版本太老，我就把 gcc 降为 2.95.3。太新的版本大多没经过大量的测试，建议不要选用。

2. 建立工作目录

首先，我们建立几个用来工作的目录：

在你的用户目录，我用的是用户liang，因此用户目录为 /home/liang，先建立一个项目目录embedded。

$pwd      /home/liang $mkdir embedded

 

再在这个项目目录 embedded 下建立三个目录 build-tools、kernel 和 tools。

build-tools-用来存放你下载的 binutils、gcc 和 glibc 的源代码和用来编译这些源代码的目录。

kernel-用来存放你的内核源代码和内核补丁。

tools-用来存放编译好的交叉编译工具和库文件。

$cd embedded $mkdir  build-tools kernel tools

 

执行完后目录结构如下：

$ls embedded build-tools kernel tools

 

3. 输出和环境变量

我们输出如下的环境变量方便我们编译。

$export PRJROOT=/home/liang/embedded $export TARGET=arm-linux $export PREFIX=$PRJROOT/tools $export TARGET_PREFIX=$PREFIX/$TARGET $export PATH=$PREFIX/bin:$PATH

 

如果你不惯用环境变量的，你可以直接用绝对或相对路径。我如果不用环境变量，一般都用绝对路径，相对路径有时会失败。环境变量也可以定义在.bashrc文件中，这样当你logout或换了控制台时，就不用老是export这些变量了。

体系结构和你的TAEGET变量的对应如下表

你可以在通过glibc下的config.sub脚本来知道，你的TARGET变量是否被支持，例如：

$./config.sub  arm-linux arm-unknown-linux-gnu

 

在我的环境中，config.sub 在 glibc-2.2.3/scripts 目录下。

网上还有一些 HOWTO 可以参考，ARM 体系结构的《The GNU Toolchain for ARM Target HOWTO》，PowerPC 体系结构的《Linux for PowerPC Embedded Systems HOWTO》等。对TARGET的选取可能有帮助。

4. 建立编译目录

为了把源码和编译时生成的文件分开，一般的编译工作不在的源码目录中，要另建一个目录来专门用于编译。用以下的命令来建立编译你下载的binutils、gcc和glibc的源代码的目录。

$cd $PRJROOT/build-tools $mkdir build-binutils build-boot-gcc build-gcc build-glibc gcc-patch

 

build-binutils-编译binutils的目录
build-boot-gcc-编译gcc 启动部分的目录
build-glibc-编译glibc的目录
build-gcc-编译gcc 全部的目录
gcc-patch-放gcc的补丁的目录

gcc-2.95.3 的补丁有 gcc-2.95.3-2.patch、gcc-2.95.3-no-fixinc.patch 和gcc-2.95.3-returntype-fix.patch，可以从http://www.linuxfromscratch.org/ 下载到这些补丁。

再将你下载的 binutils-2.10.1、gcc-2.95.3、glibc-2.2.3 和 glibc-linuxthreads-2.2.3 的源代码放入 build-tools 目录中. 看一下你的 build-tools 目录，有以下内容：

$ls binutils-2.10.1.tar.bz2     build-gcc                        gcc-patch build-binutls            build-glibc             glibc-2.2.3.tar.gz build-boot-gcc           gcc-2.95.3.tar.gz         glibc-linuxthreads-2.2.3.tar.gz

 

建立内核头文件

把你从 www.kernel.org 下载的内核源代码放入 $PRJROOT /kernel 目录

进入你的 kernel 目录：

$cd $PRJROOT /kernel

 

解开内核源代码

$tar -xzvf linux-2.4.21.tar.gz

 

或

$tar -xjvf linux-2.4.21.tar.bz2

 

小于 2.4.19 的内核版本解开会生成一个 linux 目录，没带版本号，就将其改名。

$mv linux linux-2.4.x

 

给 Linux 内核打上你的补丁

$cd linux-2.4.21 $patch -p1 < ../patch-2.4.21-rmk2

 

编译内核生成头文件

$make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig

你也可以用 config 和 xconfig 来代替 menuconfig，但这样用可能会没有设置某些配置文件选项和没有生成下面编译所需的头文件。推荐大家用 make menuconfig，这也是内核开发人员用的最多的配置方法。配置完退出并保存，检查一下的内核目录中的 include/linux/version.h 和 include/linux/autoconf.h 文件是不是生成了，这是编译 glibc 是要用到的，version.h 和 autoconf.h 文件的存在，也说明了你生成了正确的头文件。

还要建立几个正确的链接

$cd include $ln -s asm-arm asm $cd asm $ln -s arch-epxa arch $ln -s proc-armv proc

 

接下来为你的交叉编译环境建立你的内核头文件的链接

$mkdir -p $TARGET_PREFIX/include $ln -s $PRJROOT/kernel/linux-2.4.21/include/linux  $TARGET_PREFIX/include/linux $in -s $PRJROOT/kernel/linux-2.4.21/include/asm-arm  $TARGET_PREFIX/include/asm

 

也可以把 Linux 内核头文件拷贝过来用

$mkdir -p $TARGET_PREFIX/include $cp -r $PRJROOT/kernel/linux-2.4.21/include/linux  $TARGET_PREFIX/include $cp -r $PRJROOT/kernel/linux-2.4.21/include/asm-arm  $TARGET_PREFIX/include

 

建立二进制工具（binutils）

binutils是一些二进制工具的集合，其中包含了我们常用到的as和ld。

首先，我们解压我们下载的binutils源文件。

$cd $PRJROOT/build-tools $tar -xvjf binutils-2.10.1.tar.bz2

 

然后进入build-binutils目录配置和编译binutils。

$cd build-binutils $../binutils-2.10.1/configure --target=$TARGET --prefix=$PREFIX

 

--target 选项是指出我们生成的是 arm-linux 的工具，--prefix 是指出我们可执行文件安装的位置。

会出现很多 check，最后产生 Makefile 文件。

有了 Makefile 后，我们来编译并安装 binutils，命令很简单。

$make $make install

 

看一下我们 $PREFIX/bin 下的生成的文件

$ls $PREFIX/bin arm-linux-addr2line  arm-linux-gasp  arm-linux-objdump    arm-linux-strings arm-linux-ar      arm-linux-ld    arm-linux-ranlib    arm-linux-strip arm-linux-as      arm-linux-nm    arm-linux-readelf  arm-linux-c++filt    arm-linux-objcopy  arm-linux-size

 

我们来解释一下上面生成的可执行文件都是用来干什么的

add2line - 将你要找的地址转成文件和行号，它要使用 debug 信息。

Ar-产生、修改和解开一个存档文件

As-gnu 的汇编器

C++filt-C++ 和 java 中有一种重载函数，所用的重载函数最后会被编译转化成汇编的标号，c++filt 就是实现这种反向的转化，根据标号得到函数名。

Gasp-gnu 汇编器预编译器。

Ld-gnu 的连接器

Nm-列出目标文件的符号和对应的地址

Objcopy-将某种格式的目标文件转化成另外格式的目标文件

Objdump-显示目标文件的信息

Ranlib-为一个存档文件产生一个索引，并将这个索引存入存档文件中

Readelf-显示 elf 格式的目标文件的信息

Size-显示目标文件各个节的大小和目标文件的大小

Strings-打印出目标文件中可以打印的字符串，有个默认的长度，为4

Strip-剥掉目标文件的所有的符号信息

建立初始编译器（bootstrap gcc）

首先进入 build-tools 目录，将下载 gcc 源代码解压

$cd $PRJROOT/build-tools $tar -xvzf  gcc-2.95.3.tar.gz

 

然后进入 gcc-2.95.3 目录给 gcc 打上补丁

$cd gcc-2.95.3 $patch -p1< ../gcc-patch/gcc-2.95.3.-2.patch $patch -p1< ../gcc-patch/gcc-2.95.3.-no-fixinc.patch $patch -p1< ../gcc-patch/gcc-2.95.3-returntype-fix.patch echo timestamp > gcc/cstamp-h.in

 

在我们编译并安装 gcc 前，我们先要改一个文件 $PRJROOT/gcc/config/arm/t-linux，把
TARGET_LIBGCC2-CFLAGS = -fomit-frame-pointer -fPIC
这一行改为
TARGET_LIBGCC2-CFLAGS = -fomit-frame-pointer -fPIC -Dinhibit_libc -D__gthr_posix_h

你如果没定义 -Dinhibit，编译时将会报如下的错误

../../gcc-2.95.3/gcc/libgcc2.c:41: stdlib.h: No such file or directory ../../gcc-2.95.3/gcc/libgcc2.c:42: unistd.h: No such file or directory make[3]: *** [libgcc2.a] Error 1 make[2]: *** [stmp-multilib-sub] Error 2 make[1]: *** [stmp-multilib] Error 1 make: *** [all-gcc] Error 2

 

如果没有定义 -D__gthr_posix_h，编译时会报如下的错误

In file included from gthr-default.h:1,                  from ../../gcc-2.95.3/gcc/gthr.h:98,                  from ../../gcc-2.95.3/gcc/libgcc2.c:3034: ../../gcc-2.95.3/gcc/gthr-posix.h:37: pthread.h: No such file or directory make[3]: *** [libgcc2.a] Error 1 make[2]: *** [stmp-multilib-sub] Error 2 make[1]: *** [stmp-multilib] Error 1 make: *** [all-gcc] Error 2

 

还有一种与-Dinhibit同等效果的方法，那就是在你配置configure时多加一个参数-with-newlib，这个选项不会迫使我们必须使用newlib。我们编译了bootstrap-gcc后，仍然可以选择任何c库。

接着就是配置boostrap gcc， 后面要用bootstrap gcc 来编译 glibc 库。

$cd ..; cd build-boot-gcc $../gcc-2.95.3/configure --target=$TARGET --prefix=$PREFIX \ >--without-headers  --enable-languages=c --disable-threads

 

这条命令中的 -target、--prefix 和配置 binutils 的含义是相同的，--without-headers就是指不需要头文件，因为是交叉编译工具，不需要本机上的头文件;(没有—with-headers看来也不需要其它的头文件!)。-enable-languages=c是指我们的 boot-gcc 只支持 c 语言。--disable-threads 是去掉 thread 功能，这个功能需要 glibc 的支持。

接着我们编译并安装 boot-gcc

$make all-gcc $make install-gcc

 

我们来看看 $PREFIX/bin 里面多了哪些东西

$ls $PREFIX/bin

 

你会发现多了 arm-linux-gcc 、arm-linux-unprotoize、cpp 和 gcov 几个文件。

Gcc-gnu 的 C 语言编译器

Unprotoize-将 ANSI C 的源码转化为 K&R C 的形式，去掉函数原型中的参数类型。

Cpp-gnu的 C 的预编译器

Gcov-gcc 的辅助测试工具，可以用它来分析和优程序。

使用 gcc3.2 以及 gcc3.2 以上版本时，配置 boot-gcc 不能使用 --without-headers 选项，而需要使用 glibc 的头文件。

建立 c 库(glibc)

首先解压 glibc-2.2.3.tar.gz 和 glibc-linuxthreads-2.2.3.tar.gz 源代码

$cd $PRJROOT/build-tools $tar -xvzf glibc-2.2.3.tar.gz $tar -xzvf glibc-linuxthreads-2.2.3.tar.gz --directory=glibc-2.2.3

 

然后进入 build-glibc 目录配置 glibc

$cd build-glibc $CC=arm-linux-gcc ../glibc-2.2.3/configure --host=$TARGET --prefix="/usr" --enable-add-ons --with-headers=$TARGET_PREFIX/include

 

CC=arm-linux-gcc 是把 CC 变量设成你刚编译完的boostrap gcc，用它来编译你的glibc。--enable-add-ons是告诉glibc用 linuxthreads 包，在上面我们已经将它放入了 glibc 源码目录中，这个选项等价于 -enable-add-ons=linuxthreads。--with-headers告诉 glibc 我们的linux内核头文件的目录位置(编译glibc库需要)。

配置完后就可以编译和安装 glibc

$make $make install_root=$TARGET_PREFIX prefix="" install

 

然后你还要修改 libc.so 文件

将GROUP ( /lib/libc.so.6 /lib/libc_nonshared.a)

改为GROUP ( libc.so.6 libc_nonshared.a)

这样连接程序 ld 就会在 libc.so 所在的目录查找它需要的库，因为你的机子的/lib目录可能已经装了一个相同名字的库，一个为编译可以在你的宿主机上运行的程序的库，而不是用于交叉编译的。

建立全套编译器（full gcc）

在建立boot-gcc 的时候，我们只支持了C。到这里，我们就要建立全套编译器，来支持C和C++。

$cd $PRJROOT/build-tools/build-gcc $../gcc-2.95.3/configure --target=$TARGET --prefix=$PREFIX --enable-languages=c,c++

 

--enable-languages=c,c++ 告诉 full gcc 支持 c 和 c++ 语言。

然后编译和安装你的 full gcc

$make all $make install

 

我们再来看看 $PREFIX/bin 里面多了哪些东西

$ls $PREFIX/bin

 

你会发现多了 arm-linux-g++ 、arm-linux-protoize 和 arm-linux-c++ 几个文件。

G++-gnu的 c++ 编译器。

Protoize-与Unprotoize相反，将K&R C的源码转化为ANSI C的形式，函数原型中加入参数类型。

C++-gnu 的 c++ 编译器。

到这里你的交叉编译工具就算做完了，简单验证一下你的交叉编译工具。

用它来编译一个很简单的程序 helloworld.c

#include <stdio.h> int main(void) {           printf("hello world\n");           return 0; } $arm-linux-gcc helloworld.c -o helloworld $file helloworld helloworld: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), not stripped

 

上面的输出说明你编译了一个能在 arm 体系结构下运行的 helloworld，证明你的编译工具做成功了。

参考资料

·         Wookey ,Chris Rutter, Jeff Sutherland, Paul Webb ,《The GNU Toolchain for ARM Target HOWTO》

·         Karim Yaghmour，《Building Embedded Linux Systems》，USA：O'Reilly，2003

 

再次在 cygwin 下编译 Android toolchain

重装系统后把 cygwin 也重新在线安装了一下，但发现 -mno-cygwin尽然不能用了，找不到 crt2.o，这些文件明明是存在的，搜索了一下官方的问答，说是安装顺序的问题，把mingw的几个包重新装一遍即可，试验了几次也没效果，无奈，只能自己找原因，看看 /lib/gcc/i686-pc-mingw32/3.4.4/specs 文件，很多路径指向了 /usr/i686-pc-mingw32/sys-root，再看看 /usr/i686-pc-mingw32/lib，也都是些指向 sys-root的 link ，而这个目录根本就不存在，真正的文件是在 /lib/mingw里的。在 /usr/i686-pc-mingw32下建一个 sys-root 目录，把 lib 下的文件复制过来，再试试编译，所有问题解决！难道说 cygwin忘记把这些文件放到安装包里？应该不是吧，cygwin也需要发展，并打算慢慢废弃一些陈旧的东西，gcc3应该也懒得继续维护，打算让用户全换到gcc4上去，众所周知cygwin的已经不支持-mno-cygwin了，需要编译纯windows的东西由独立的mingw64以cross toolchain方式替代。毕竟mingw是独立的，并非cygwin的一部分，而且mingw的MSYS在某些方面足以跟 cygwin 唱对台戏。要让 cygwin花巨大精力去做 NO-CGYWIN的东西，确实强人所难了，但遗憾的是，历史遗留下来的大量依赖-mno-cygwin的编译脚本也将被统统废弃，可惜了。

言归正题，虽然虚拟化技术在windows里跑个linux是很容易的事，但我还是喜欢用cygwin，为了继续andorid研究，在cygwin编译套新的Android toolchain是必须的。网上搜索新的教程，很是郁闷，搜到基本都是我三年前的帖子和别人转贴。算了，重新再来：

1.下载toolchain源码

  repo 安装不多说了，但在cygwin下用 repo需要装 git 和 python 包，在64位win7下，python还出异常，需要关闭cygwin，运行bin目录下的ash，并在ash提示符中运行 /bin/rebaseall 。(还可能出现windows的temp目录不可写的错误，chmod加写入权限，不知道会不会给win自身的安全带来隐患，不放心的话，rebaseall结束后，再改回去吧)

  # mkdir android-toolchain
  # cd android-toolchain

  # repo -u git://android.git.kernel.org/toolchain/manifest.git

  # repo sync

  大概需要下载280M左右的东西，但对我这下载平均不过5K的速度来说，太痛苦了...

2. 准备编译toolchain

  编译前先仔细阅读刚下载的目录中build目录下的 README，目前的toolchain允许编译出4个目标toolchain，作为一般使用，我们只关心前两个即适合NDK使用的 arm-linux-androideabi 和用来编译android内核的 arm-eabi。看gcc部分也有4套版本的源码可供选择，印象中4.2.1不支持cortex-a8的指令集，所以如果要做ARMv7的代码，需要选更高的版本，当然高版本的gcc也需要高版本的gmp和mpfr库。检查一下cygwin是否装齐了各工具包，比如 gcc make flex bison gettext textinfo ，印象中 gettext-devel一定要装的。

  # mkdir arm-eabi

  # cd arm-eabi

  # ../android-toolchain/build/configure --target=arm-eabi --prefix=/opt/arm-eabi --disable-libstdc__-v3

  # make build

  # make install

 没想到编译过程出奇的顺利，N个小时后，编译脚本正常结束。得到编译内核用的 arm-eabi，gcc版本4.2.1。这还不是目前真正需要的东西，把 /opt/arm-eabi 打包，备份，以后可能用的到。~/arm-eabi目录也没什么用了，可以直接删除。我们其实需要是 gcc4.4.x的arm-linux-androideabi。这还需要 --with-sysroot=<path to sysroot>，一个包含针对 android指定版本的 sysroot目录，在 build 目录里有个脚本 build-sysroot.sh，可以帮助从 android源码的编译结果中提取需要的文件创建 android toolchain的 sys-root ，但这这个脚本很邪恶，如果你用的root账户(cygwin里基本就是root)，如果你没加任何参数指行了那个脚本，呵呵，你的系统基本需要重装了，因为 /usr/lib 和 /usr/include会被删的一干二净。务必注意！cygwin应该是不可能编译android源码的，所以只能找编译好的，比如 prebuilt/ndk/android-ndk-r4/platforms/ 下的目录。(该目录在android的源码中。也可以只 git platform/prebuilt，大概1.1G的下载量，有条件的不防把整个 platform全部 repo 一份留之备用)。如果没有下载 android源码，在 toolchain\benchmark\android_build\eclair也可以找到，但只是预编译结果，需要用 build-sysroot.sh脚本从那个目录里选择复制文件生成 sysroot。

 # mkdir android-eabi

 # cd android-eabi

 # mkdir sys-root

把 toolchian/build/build-sysroot.sh复制到 android-eabi目录下打开编辑

 DYNAMIC_LIBS_DIR=$PRODUCT_DIR/symbols/system/lib 改成 DYNAMIC_LIBS_DIR=$PRODUCT_DIR/obj/lib

 install $BIONIC_ROOT/libm/include/arm/fenv.h $INCLUDE_ROOT改成 install $BIONIC_ROOT/libm/arm/fenv.h $INCLUDE_ROOT

执行脚本(切记参数别搞错!!!)

 # ./build-sysroot.sh ~/android-toolchain/benchmark/android_build/eclair/out/target/product/passion ~/android-eabi/sys-root

 不明白为什么一个简单的文件复制脚本在 cygwin下执行要花很常时间，总之执行完成，即可得到 eclair的 sysroot 了。保险起见，这个build-sysroot.sh还是删除的好 (祸端啊，害我重装N次cygwin)。

3. 开始编译，cygwin的编译器需要gcc4 (cygwin的gcc3和gcc4可以同时安装，用set-gcc-default-?.sh可切换)

 # ../android-toolchain/build/configure --target=arm-linux-androideabi --prefix=/opt/arm-linux-androideabi --with-gcc-version=4.4.3 --with-binutils-version=2.20.1 --with-gmp-version=4.2.4 --with-mpfr-version=2.4.1 --with-gdb-version=7.1.x --with-gold-version=20100303 --with-sysroot=~/android-eabi/sys-root --enable-gold=both/gold

 #make build

 #make install

编译过程没有什么问题，但因为没有编译stdc++_v3，install 过程会出错，gcc 目录下 Makefile中 install-target节删除 maybe-install-target-libstdc++-v3 maybe-install-target-libgcc maybe-install-target-libiberty三行可解决。安装后的编译器基本功能都有了，但跟android源码中prebuild下的toolchain似乎还有点差距。

 

Glibc移植到android调查小结

http://www.newsmth.net/nForum/#!article/LinuxDev/41045

结论是，需要的工作量太大，还不如把代码移植到bionic库合适。

目的：调查Glibc如何最小修改使其可以在Android平台上使用。

应用场景：
Linux的现有应用程序或库需要移植到Android上，一般来说都要修改源码使其适合Android自己重新实现的C库Bionic。Bionic相对于Glib更简略，更高效，但是有些Glibc中有的库函数或者包装的syscall在bionic中没有实现，如果Linux原来的应用程序或者库使用到了这些bionic没有实现函数，那就要做相应修改才能让程序编译运行。

能想到的修改方法有三种：
1、    修改程序源程序，实现相应功能的函数或者寻找替代函数。
2、    修改bionic库添加相应函数或syscall。
3、    移植glibc到android上面，作为一个普通的动态链接库让程序调用，这也是本次调查的主题。

目前试验过的移植方法:
1、编译时候使用glibc静态库链接，静态链接可以直接跑起来。但是把所有的库或程序都静态链接不合适，可执行文件太大了。

2、将glibc单独函数包装成动态库，实验情况如下：
单独将printf(在glibc和bionic中都实现)包裹一层做成一个so，可以正常调用。
相关输出信息：
DEBUG:   252 Processing 'libhello.so' relocation at index 0
   252 SEARCH printf in libhello.so@0x80000000 077905a6 2
   252 SEARCH printf in libdl.so@0x00000000 077905a6 0
   252 SEARCH printf in ./dlopentest-new@0x00000000 077905a6 2
   252 SEARCH printf in libc.so@0xafe00000 077905a6 152
   252 FOUND printf in libc.so (00014359) 44                <---在android自己的C库中找到了函数定义
   252 printf s->st_value = 0x00014359, si->base = 0xafe00000
   252 RELO JMP_SLOT 80008360 <- afe14359 printf
DEBUG: [   252 finished linking libhello.so ]
   252 SEARCH hello in libhello.so@0x80000000 006ec32f 1
   252 FOUND hello in libhello.so (00000280) 60

单独将getline(在glibc实现了，bionic中没有实现)包裹一层做成一个so，调用错误。
相关输出信息：
DEBUG:   258 Processing 'libgetline.so' relocation at index 0
   258 SEARCH getline in libgetline.so@0x80000000 0dcb3025 1
   258 SEARCH getline in libdl.so@0x00000000 0dcb3025 0
   258 SEARCH getline in ./getlinetest@0x00000000 0dcb3025 12
   258 SEARCH getline in libc.so@0xafe00000 0dcb3025 650
   258 SEARCH getline in libstdc++.so@0xafd00000 0dcb3025 0
   258 SEARCH getline in libm.so@0xafc00000 0dcb3025 101
/android_source/google_android_dount/bionic/linker/linker.c:1172| ERROR:   258 cannot locate 'getline'...
/android_source/google_android_dount/bionic/linker/linker.c:1698| ERROR: failed to link libgetline.so
在Android的C库中找不到这个函数的实现。

3、编译时使用glibc动态库，使用glibc库自己的dynamic loader---ld-linux.so
参见：http://groups.google.com/group/android-internals/browse_thread/thread/7c728a36474fbc05
方法就是在编译时指定dynamic loader为ld-linux.so，例如：
arm-none-linux-gnueabi-gcc -o hello.out hello.c -Wl,-dynamic-linker=/ system/lib/ld-linux.so.6
我试了一下，hello world可以跑，大型复杂程序不知道会如何，需要考虑效率，IPC方式等很多问题。

4、    编译时使用glibc动态库，使用bionic库自己的dynamic loader---linker
实验情况如下：
相关输出信息：
DEBUG:   256 Processing 'libc.so.6' relocation at index 1185
/android_source/google_android_dount/bionic/linker/linker.c:1288| ERROR:   256 unknown reloc type 19  
@ 0x80014ee0 (1185)
/android_source/google_android_dount/bionic/linker/linker.c:1698| ERROR: failed to link libc.so.6
在进行Link的relocation时候发生错误，链接过程还没结束就出错，根本没有查找有没有printf这个函数可用。
查了一下reloc type 19的定义是：R_ARM_TLS_TPOFF32，是和线程本地存储相关的一个relocation。
从代码和网络查了一下，android目前对TLS支持十分有限，而且目前的实现也有问题。
参见：
http://groups.google.com/group/android-ndk/browse_thread/thread/4f60d0201464b7f4/8821e4d791e5be35?lnk=raot
http://groups.google.com.tw/group/0xlab-devel/browse_thread/thread/69239c9b773d3c59
http://elinux.org/Android_on_OMAP#TLS_issue
而且Linker（1.6的代码）中没有关于TLS的代码。
我想到的另外一个原因是linker/README.txt里写的：

线程本地数据相关的数据要链接到执行程序映像，会有分配内存的动作。
THE DYNAMIC LINKER CANNOT USE malloc()/free() !That's why it is linked to a special version of the C library that will abort when any of these functions (or calloc()/realloc()) is called.

所以单纯把libc.so.6和其相关的so拿到android上使用android自己的linker肯定是有问题的。
而且这还没有考虑到bionic中还有没有实现的linux syscall接口和即使TLS问题解决，还会有其他的底层问题出现。
试图重新编译Glibc去掉TLS特性，在glibc上的官方文档上的编译选项中有—without-tls，但是具体到ARM交叉编译的时候发现arm的ports库里面tls.h有如下语句：
/* We require TLS support in the tools.  */
#ifndef HAVE_TLS_SUPPORT
# error "TLS support is required."
#endif
导致编译错误。

目前调查如何修改bionic的linker使其适应libc.so。