arm-linux的交叉編譯環(huán)境的建立

zj47596731

一、交叉編譯環(huán)境介紹

交叉編譯是嵌入式開發(fā)過程中的一項重要技術(shù)，其主要特征是某機器中執(zhí)行的程序代碼不是在本機編譯生成，而是由另一臺機器編譯生成，一般把前者稱為目標(biāo)機，后者稱為主機。

采用交叉編譯的主要原因在于，多數(shù)嵌入式目標(biāo)系統(tǒng)不能提供足夠的資源供編譯過程使用，因而只好將編譯工程轉(zhuǎn)移到高性能的主機中進行，這就需要在強大的pc機上建立一個用于目標(biāo)機的交叉編譯環(huán)境。這是一個由編譯器、連接器和解釋器組成的綜合開發(fā)環(huán)境。

linux下的交叉編譯環(huán)境重要包括以下幾個部分：

     1，針對目標(biāo)系統(tǒng)的編譯器gcc；

     2，針對目標(biāo)系統(tǒng)的二進制工具binutils；

     3，目標(biāo)系統(tǒng)的標(biāo)準(zhǔn)c庫glibc，有時出于減小libc 庫大小的考慮，你也可以用別的c庫來代替glibc，例如uClibc、newlib等；

     4，目標(biāo)系統(tǒng)的linux內(nèi)核頭文件。

二、準(zhǔn)備工作

       本文實驗所使用的主機環(huán)境為cygwin，所以在編譯交叉工具鏈的時候要注意cygwin版本的問題，建議將cygwin在線升級至最新版本，本文試驗中cygwin DLL版本號為1.5.21。

       因為gcc、binutils、glibc以及linux內(nèi)核頭文件均有各自的版本號，并不是任意組合都可以編譯成功并最終建立一個交叉編譯環(huán)境的。一些可以直接利用的組合方式，可以通過該網(wǎng)址查看：http://kegel.com/crosstool/ 當(dāng)我們選擇了某一種組合以后，仍然需要對源代碼做相應(yīng)的修改，才能最終編譯成功。

       本文使用的組合為gcc-3.4.5+glibc-2.2.5+binutils-2.15+linux-2.6.8(頭文件)，因為本文建立的交叉編譯環(huán)境是用來編譯linux-2.6系列內(nèi)核，以及運行在該系列內(nèi)核上的程序，故選擇了linux-2.6.8內(nèi)核的頭文件，當(dāng)然也可以選擇其他合適的linux-2.6版本的內(nèi)核。

       針對上面的這種組合，我們還需要打相應(yīng)的補丁，這些補丁可以通過如下網(wǎng)址下載到：http://kegel.com/crosstool/crosstool-0.42.tar.gz 解壓后在patch文件夾中可以找到相應(yīng)的補丁。下面給出一些下載的鏈接，便于下載。

三、交叉編譯環(huán)境的建立過程

為了更清晰的描述交叉環(huán)境的建立過程，在此對各個源碼包的作用進行說明。

binutils-2.15.tar.bz2：這個壓縮包包含有ld,ar,as等一些產(chǎn)生或者處理二進制文件的工具。其主要目的是為GNU系統(tǒng)提供匯編和連接工具等。

gcc-3.4.5.tar.bz2：這個壓縮包主要是為GNU系統(tǒng)提供C 編譯器�，F(xiàn)在支持多種語言，這其中包括C/C++、Fortran、Java、Objective-C、Ada等。

       glibc-2.2.5.tar.gz：Libc是很多用戶層應(yīng)用都要用到的庫，用于定義系統(tǒng)調(diào)用和其它一些基本的函數(shù)調(diào)用。

       glibc-linuxthreads-2.2.5.tar.gz：這是Libc用于支持Posix線程而單獨發(fā)布的一個壓縮包。

      linux-2.6.8.tar.bz2：這個壓縮包就是Linux的內(nèi)核，在編譯glibc時，要用到Linux內(nèi)核中的include目錄的內(nèi)核頭文件。

交叉編譯環(huán)境建立過程如下，同時圖3-1也清晰地描述了此過程。

（1）創(chuàng)建編譯環(huán)境。在這個過程中，將設(shè)置一些環(huán)境變量，創(chuàng)建安裝目錄，安裝內(nèi)核源代碼和頭文件等。

（2）建立內(nèi)核頭文件，主要是生成include/linux/version.h 和 include/linux/autoconf.h 文件，這是編譯 glibc 是要用到的，version.h 和 autoconf.h 文件的存在，也說明了你生成了正確的頭文件。

（3）創(chuàng)建binutils。這個過程結(jié)束后，會創(chuàng)建類似arm-linux-ld等工具。binutils是一組開發(fā)工具，包括鏈接器、匯編器以及其他用于目標(biāo)文件和檔案的工具.首先安裝軟件包binutils是非常重要的，因為glibc和gcc會針對可用的連接器和匯編器進行多種測試，以決定打開某些特性。

（4）創(chuàng)建一個交叉編譯版本的gcc（稱為bootstrap gcc）。注意：在這個過程中只能編譯C程序，而不能編譯C++程序。創(chuàng)建一個完整的交叉編譯版本gcc，需要交叉編譯版本的glibc及其頭文件，而交叉編譯版本的glibc是通過交叉編譯版本的gcc創(chuàng)建的。面對這個先有雞還是先有蛋的問題，解決辦法是先編譯僅支持C語言的bootstrap gcc編譯器，并禁止支持線程。

（5）創(chuàng)建一個交叉編譯版本的glibc。這里最容易出現(xiàn)問題。glibc是一個提供系統(tǒng)調(diào)用和基本函數(shù)的C語言庫，比如open,malloc和printf等，所有動態(tài)鏈接的程序都要用到它。創(chuàng)建glibc需要的時間很長。

（6）重新創(chuàng)建gcc（稱為full gcc）。因為前面創(chuàng)建gcc的過程沒有編譯C++編譯器，現(xiàn)在glibc已經(jīng)準(zhǔn)備好了，所以這個步驟將產(chǎn)生一個更完整的full gcc編譯器。

圖3-1 交叉編譯環(huán)境建立過程

四、交叉環(huán)境的建立 4．1工作目錄及環(huán)境變量的設(shè)置

因為項目空間中目錄眾多, 我們可以通過export命令設(shè)置一些環(huán)境變量以方便后面的工作，見表4-1。目錄結(jié)構(gòu)如圖4-1所示。

圖4-1 目錄結(jié)構(gòu)圖

4．2、建立內(nèi)核頭文件

因為交叉工具鏈工具鏈?zhǔn)轻槍μ囟ǖ奶幚砥骱筒僮飨到y(tǒng)的，因此在編譯之前就需要對linux內(nèi)核進行配制，可以通過“make config”或“make menuconfig”命令對內(nèi)核進行配制，配制完成后，在linux源文件的目錄下就會生成一個.config文件，這就是我們所需要的文件。如果你有現(xiàn)成的配制文件，可以在“make menuconfig”中加載進來，或者使用cp命令把配制文件復(fù)制到linux源文件目錄下并改名為.config。

此時的.config還不是完整的，因為有些信息在配置文件中沒有給出，需要用戶通過控制臺輸入，可以使用“make ARCH=arm oldconfig”命令，該命令可以使內(nèi)核設(shè)置進程讀取用戶已有的設(shè)置信息，從而提示用戶輸入某一內(nèi)核設(shè)置變量的值,這一變量在已有的內(nèi)核設(shè)置文件中是找不到的,此處ARCH=arm就是我們輸入的值。

接下來執(zhí)行如下命令產(chǎn)生相關(guān)文件和鏈接：

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

執(zhí)行完后，在linux2.6.8/include目錄下生成version.h和autoconfig.h。這兩個文件，在編譯glibc時會用到。至此，linux的頭文件已經(jīng)生成完畢，現(xiàn)在通過如下命令，將編譯交叉工具鏈時用到的頭文件拷貝到$HEADERDIR目錄下。圖4-2為目錄結(jié)構(gòu)圖。

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

cp -r include/linux $HEADERDIR

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

 

圖4-2 linux內(nèi)核頭文件目錄結(jié)構(gòu)

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

首先安裝二進制工具鏈，使用主機的gcc進行編譯。生成的交叉二進制工具arm-linux-ar,arm-linux-as,arm-linux-ld等是編譯其他交叉程序的基礎(chǔ)，所以必須放到第一步進行。編譯過程如下：

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工具生成以后，要將其路徑加入環(huán)境變量PATH中，以便在后續(xù)編譯過程中能夠找到它們。生成的工具如圖4-3所示。

圖4-3 生成的binutils工具

4．4、建立初始編譯器（bootstrap gcc）

為了生成交叉編譯版的glibc，我們就必須創(chuàng)建一個交叉編譯版本的gcc。但是在資源有限的條件下，不可能擁有一個完整的交叉編譯版的gcc（因為編譯完整的gcc是需要交叉編譯版的glibc及其頭文件，而現(xiàn)在還沒有）。我們現(xiàn)在只能夠先利用主機的gcc編譯出一個簡單的交叉編譯版gcc，即arm-linux-gcc及相關(guān)工具。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生成以后，要將其路徑加入環(huán)境變量PATH中，以便在后續(xù)編譯過程中能夠找到它們。生成的工具如圖4-4所示。

圖4-4 生成bootstrap gcc后的目錄結(jié)構(gòu)圖

4．5、建立c庫(glibc)

glibc是一個提供系統(tǒng)調(diào)用和基本函數(shù)的C語言庫，比如open,malloc和printf等，所有動態(tài)鏈接的程序都要用到它，這里最容易出現(xiàn)問題，并且創(chuàng)建glibc需要的時間很長。這時候編譯器將會使用上一步生成的arm-linux-gcc，同時會用到一開始準(zhǔn)備的linux內(nèi)核頭文件。編譯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）

因為前面創(chuàng)建gcc的過程沒有編譯C++編譯器，現(xiàn)在glibc已經(jīng)準(zhǔn)備好了，所以這個步驟將產(chǎn)生一個更完整的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

       至此，已經(jīng)生成一個完整的交叉編譯版gcc，此時生成的arm-linux-gcc等工具和4.3節(jié)生成的arm-linux-gcc并不相同，完整的交叉編譯版的gcc被添加至$PREFIX/bin目錄，其結(jié)構(gòu)如圖4-5所示。

 

 

圖4-5生成full gcc后的目錄結(jié)構(gòu)圖

五、configure選項說明

完整的信息可以參考gcc-3.4.5\INSTALL\configure.html

--prefix=dirname

Specify the toplevel installation directory. This is the recommended way to install the tools into a directory other than the default. The toplevel installation directory defaults to /usr/local.

--with-local-prefix=dirname

Specify the installation directory for local include files. The default is /usr/local. Specify this option if you want the compiler to search directory dirname/include for locally installed header files instead of /usr/local/include.

You should specify --with-local-prefix only if your site has a different convention (not /usr/local) for where to put site-specific files.

The default value for --with-local-prefix is /usr/local regardless of the value of --prefix. Specifying --prefix has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical.

The purpose of --prefix is to specify where to install GCC. The local header files in /usr/local/include—if you put any in that directory—are not part of GCC. They are part of other programs—perhaps many others. (GCC installs its own header files in another directory which is based on the --prefix value.)

Both the local-prefix include directory and the GCC-prefix include directory are part of GCC's "system include" directories. Although these two directories are not fixed, they need to be searched in the proper order for the correct processing of the include_next directive. The local-prefix include directory is searched before the GCC-prefix include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories.

Some autoconf macros add -I directory options to the compiler command line, to ensure that directories containing installed packages' headers are searched. When directory is one of GCC's system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched.

GCC automatically searches for ordinary libraries using GCC_EXEC_PREFIX. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is installed as a system compiler in /usr.

Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the --program-prefix, --program-suffix and --program-transform-name options to install multiple versions into a single directory, but it may be simpler to use different prefixes and the --with-local-prefix option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries (e.g., with LIBRARY_PATH).

The same value can be used for both --with-local-prefix and --prefix provided it is not /usr. This can be used to avoid the default search of /usr/local/include.

--enable-shared[=package[,...]]

Build shared versions of libraries, if shared libraries are supported on the target platform. Unlike GCC 2.95.x and earlier, shared libraries are enabled by default on all platforms that support shared libraries, except for `libobjc' which is built as a static library only by default.

If a list of packages is given as an argument, build shared libraries only for the listed packages. For other packages, only static libraries will be built. Package names currently recognized in the GCC tree are `libgcc' (also known as `gcc'), `libstdc++' (not `libstdc++-v3'), `libffi', `zlib', `boehm-gc' and `libjava'. Note that `libobjc' does not recognize itself by any name, so, if you list package names in --enable-shared, you will only get static Objective-C libraries. `libf2c' and `libiberty' do not support shared libraries at all.

Use --disable-shared to build only static libraries. Note that --disable-shared does not accept a list of package names as argument, only --enable-shared does.

--with-sysroot

--with-sysroot=dir

Tells GCC to consider dir as the root of a tree that contains a (subset of) the root filesystem of the target operating system. Target system headers, libraries and run-time object files will be searched in there. The specified directory is not copied into the install tree, unlike the options --with-headers and --with-libs that this option obsoletes. The default value, in case --with-sysroot is not given an argument, is ${gcc_tooldir}/sys-root. If the specified directory is a subdirectory of ${exec_prefix}, then it will be found relative to the GCC binaries if the installation tree is moved.

--with-headers

--with-headers=dir

Deprecated in favor of --with-sysroot. Specifies that target headers are available when building a cross compiler. The dir argument specifies a directory which has the target include files. These include files will be copied into the gcc install directory. This option with the dir argument is required when building a cross compiler, if prefix/target/sys-include doesn't pre-exist. If prefix/target/sys-include does pre-exist, the dir argument may be omitted. fixincludes will be run on these files to make them compatible with GCC.

--without-headers

Tells GCC not use any target headers from a libc when building a cross compiler. When crossing to GNU/Linux, you need the headers so GCC can build the exception handling for libgcc. See CrossGCC for more information on this option.

--with-libs

--with-libs=``dir1 dir2 ... dirN''

Deprecated in favor of --with-sysroot. Specifies a list of directories which contain the target runtime libraries. These libraries will be copied into the gcc install directory. If the directory list is omitted, this option has no effect.

--with-newlib

Specifies that `newlib' is being used as the target C library. This causes __eprintf to be omitted from libgcc.a on the assumption that it will be provided by `newlib'.