的应用程序的构造过程有显著不同；内核是一个大的、独立的程序
,
对于它的各
个部分如何组合在一起有详细的明确的要求。
Linux2.6
内核的构造过程也与以
前版本的内核构造过程不同；
新的构造系统用起来更加简单，
并且可产生更加正
确的结果
,
但是它看起来和先前的方法有很大不同。内核的构造系统非常复杂
,
我们所看到的只是它的一小部分。
如果读者想了解更深入的细节，
则应阅读在内
核源码中的
Document/kbuild
目录下的文件。
在构造内核模块之前，
有一些先决条件首先应该得到满足。
首先，
读者要保证你
有适合于你的内核版本的编译器、模块工具
,
以及其他必要工具。在内核文档目
录下的文件
Documentation/Changes
里列出了需要的工具版本；
在开始构造内
核前，
读者有必要查看该文件，
并确保已安装了正确的工具。
如果用错误的工具
版本来构造一个内核
(
及其模块
)
，可能导致许多奇怪的问题。另外也要注意
,
使
用太新版本的编译器偶尔可能也会导致问题。
一旦做好了上面的准备工作之后
,
其实给自己的模块创建一个
makefile
则非常
简单。实际上
,
对于本章前面展示的
" hello world"
例子
,
下面一行就够了
:
obj-m := hello.o
如果读者熟悉
make
，
但是对
Linux2.6
内核构造系统不熟悉的话
,
可能奇怪这个
makefile
如何工作。毕竟上面的这一行不是一个传统的
makefile
的样子。问
题的答案当然是内核构造系统处理了余下的工作。上面的赋值语句
(
它利用了由
GNU make
提供的扩展语法
)
说明有一个模块要从目标文件
hello.o
构造，而从
该目标文件构造的模块名称为
hello.ko.
如果我们想由两个源文件
(
比如
file1.c
和
file2.c )
构造出一个名称为
module.ko
的模块
,
则正确的
makefile
可如下编写
:
obj-m := module.o
module-objs := file1.o file2.o
为了让上面这种类型的
makefile
文件正常工作
,
必须在大的内核构造系统环境
中调用他们。假设读者的内核源码数位于
~/kernel-2.6
目录
,
用来建立你的模
块的
make
命令
(
在包含模块源代码和
makefile
的目录下键入
)
应该是
:
make -C ~/kernel-2.6 M=`pwd` modules
这个命令首先是改变目录到用
-C
选项指定的位置
(
即内核源代码目录
)
，其中保
存有内核的顶层
makefile
文件。这个
M=
选项使
makefile
在构造
modules
目
标前
,
返回到模块源码目录。
然后，
modules
目标指向
obj-m
变量中设定的模块，
在上面的例子里，我们将该变量设置成了
module.o
。
上面这样的
make
命令对于多个文件的编译显得不是很方便
,
于是内核开发者就
开发了一种
makefile
方式
,
这种方式使得内核树之外的模块构造变得更加容易。
代码清单
1.4
展示了
makefile
的编写方法：
代码清单
1.4 makefile
ifeq ($(KERNELRELEASE),)
KERNELDIR ?= /source/linux-2.6.13
PWD := $(shell pwd)
modules:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
modules_install:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install
clean:
rm -rf *.o *~ core .depend .*. *.ko *.mod.c .tmp_versions
.PHONY: modules modules_install clean
else
obj-m := hello.o
endif
我们再次看到了扩展的
GNU
make
语法在起作用。在一个典型的构造过程中，这
个
makefile
将被读取两次。当从命令行中调用这个
makefile ,
它注意到
KERNELRELEASE
变量尚未设置。我们可以注意到，已安装的模块目录中存在一
个符号连接，
它指向内核的构造树，
这样这个
makefile
就可以定位内核的源代
码目录。如果读者时间运行的内核并不是要构造的内核，则可以在命令行提供
KERNELDIR=
选项或者设置
KERNELDIR
环境变量
,
或者修改
makefile
中设置
KERNELDIR
的那一行。在找到内核源码树
,
这个
makefile
会调用
default:
目
标
,
这个目标使用先前描述过的方法第二次运行
make
命令
(
注意，在这个
makefile
里
make
命令被参数化成
$(MAKE))
，以便运行内核构造系统。在第二
次读取
makefile
时，
它设置了
obj-m,
而内核的
makefile
负责真正构造模块。
这种构造模块的机制看起来很繁琐，可是，一旦我们习惯了使用这种机制
,
则会
欣赏内核构造系统带给我们的便利。需要注意的是
,
上面
makefile
并不完整，
一个真正的
makefile
应包含通常用来清除无用文件的目标
,
安装模块的目标等
等。一个完整的例子可以参考例子代码目录的
makefile
。
大致目录构建如下：├── uc-config.in : 用来生成配置环境信息的可执行程序
├── uc.pc.in : 用来生成配置环境信息的文件
├── uc.spec.in : 用来产生spec文件
├── autogen.sh : build工具
├── conf : 配置文件目录
├── config.h.in : 一些编译过程中的配置信息
├── configure : 配置工具
├── configure.ac : 形成build以及配置工具的文件
├── data : 数据目录
├── doc : 文档
├── Doxyfile.in : 生成Doxyfile的文件，主要用于doxygen的配置文件
├── include : 外部的头文件，工程内的文件不要放入
├── lib : 外部的库文件，工程内的库不要放入
├── m4 : m4文件
├── scripts : 常使用的一些script，用于运转系统
├── src : 源代码目录
│ ├── xxxMain.cpp : 用于产生xxx的gnome版本的源文件，含有main入口
│ ├── xxx.h : 用于外部开发的xxx接口
│ ├── xxxMain.cpp：用于产生xxx的kde版本，含有kde的main入口
│ ├── common : 普通的头文件
│ │ ├── xxxdef.h ： xxx的一般定义
│ │ ├── xxxrst.h ： xxx的返回值类型定义
│ │ ├── xxxtypes.h : xxx的类型定义
│ │ ├── common.h : 共用头文件，含有xxxdef.h、xxxrst.h和xxxtypes.h等头文件
│ ├── network : 网络通讯库
│ ├── ui : ui界面库
│ │ ├── gnome : gnome界面库，主要是gtk2的一些界面接口
│ │ ├── kde : kde界面库，主要是qt的一些界面接口
│ └── util : 常用的一些共用库
├── test : 单元测试
│ ├── dotest.cpp : 主要测试入口
│ ├── network
│ ├── template.cpp : 样例模板 cpp 文件
│ ├── template.h : 样例模板 头文件
│ ├── ui
│ │ ├── gnome
│ │ └── kde
│ └── util
└── tools : 常使用的一些工具，用于维护系统
如何编写configure.ac
configure.ac是产生configure以及automake重要文件，一般可以使用autoscan生成，这里就不太详细描述，网上可以google到很多资料。
一般开发人员只需要使用autogen.sh，这个脚本会完成所有的automake以及autoconf的 *** 作，虽然其中m4文件定义的宏非常重要，但是不需要开发人员完全读懂，这里也不是关注的重点，等一步步的完全熟悉了，再过来了解也不迟。
这里项目中默认已经生成好了configure.ac。
如何编译Makefile.am
开发人员重点关注的是Makefile.am，Makefile.am完全和Makefile的语法一样，不过你可以写少量的信息就足够了。
如何编译源文件
这里所指的源文件一般指c/c++源文件，对于java的源文件，我们将ant放入Makefile.am，道理一样。编译源文件一般有两种方式，库文件和可执行文件，而库文件也有两种方式，静态库文件和动态库文件，一般静态库用：
lib_LIBRARIES = libcpthread.a
这种方式表示生成一个静态库，对应的源文件如何写呢？
libcpthread_a_SOURCES = thread.cpp thread.h
当然对于一般头文件可以忽略不写，不过建议写上，因为每个开发者都不是很规范，头文件不仅仅只有申明，有的头文件还会有实现。如果有多个cpp文件生成一个库文件，则全部添加；如果有多个.a文件需要生成，只需要用空格隔开.a文件，相应的源文件对应到.a文件即可，如下所示：
lib_LIBRARIES = libcpthread1.a libcpthread2.a libcpthread2.a
那么动态库该如何写呢？有人肯定会提到
lib_LIBRARIES = libcpthread.so
libcpthread_so_SOURCES = thread.cpp thread.h
不过可惜是错误的，这里顺便提到一个libtool，主要用来生成静态库和动态库的一个工具，不过在autogen.sh工具里面已经包含。正确写法如下：
lib_LTLIBRARIES = libcpthread.la
libcpthread_la_SOURCES = thread.cpp thread.h
有人看到这觉得很奇怪，为什么要生成.la这个文件呢？.la文件内容如下：
# libcpthread.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.
# The name that we can dlopen(3).
dlname='libcpthread-1.0.0.so.1'
# Names of this library.
library_names='libcpthread-1.0.0.so.1.0.0 libcpthread-1.0.0.so.1 libcpthread.so'
# The name of the static archive.
old_library='libcpthread.a'
# Libraries that this one depends upon.
dependency_libs=' -ldl /usr/lib64/libconfig++.la /usr/lib64/libconfig.la /usr/lib64/libchardet.la /usr/local/lib64/libalog.la -lz /usr/local/lib64/libanet.la -lpthread -lalog'
# Version information for libcpthread.
current=1
age=0
revision=0
# Is this an already installed library?
installed=no
# Should we warn about portability when linking against -modules?
shouldnotlink=no
# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''
# Directory that this library needs to be installed in:
libdir='/usr/lib'
看到了吧？里面指定了关于静态库和动态库的依赖等一系列的信息，具体还可以参考项目框架设计模式中库公约的部分。
静态文件和动态文件都会在当前目录的.libs下，当然开发者也不需要关注库文件本身，了解在这个路径下即可。
可执行文件如何编译呢？
bin_PROGRAMS = threadpool
threadpool_SOURCES = threadpoolMain.cpp
此处的bin_PROGRAMS会将程序安装到${prefix}路径下，如果不想安装，可以采用：
noinst_PROGRAMS = testthreadpool
threadpool_SOURCES = threadpoolMain.cpp
同理，如果有多个cpp文件生成一个库文件，则全部添加；如果有多个.la文件或者可执行文件需要生成，只需要用空格隔开.a文件，相应的源文件对应到.a文件即可，如下所示：
lib_LTLIBRARIES = libcpthread1.la libcpthread2.la libcpthread2.la
noinst_PROGRAMS = testthreadpool1 testthreadpool2 testthreadpool3
如果库文件或者二进制文件有头文件的申明依赖或追加一些编译选项，则可以使用CFLAGS或CPPFLAGS，如下所示：
threadpool_CPPFLAGS = -I$(top_srcdir)/include/example.h
如果是java源文件,只需要遵循普通makefile写法即可，如：
all: threadpool.jar
.PHONY: threadpool.jar clean
threadpool.jar:
@ant jar
clean:
ant clean
当然，ant需要配置好build.xml哟！
如何连接库
连接库的的时候，同样也会有区分，工程外部的连接需使用LDFLAGS，如下所示：
libcpthread_la_LDFLAGS = -pthread
如果是内部库，我们就直接使用.la文件，这样在选择静态连接或者动态连接的时候，就给开发者很大的空间。值得注意的是，库文件和二进制的内部库连接宏并不相同，表现如下：
libcpthread_la_LIBADD = $(top_srcdir)/src/util/libutil.la
threadpool_LDADD = libcpthread.la
现在编译和连接是否都了解了呢？
非编译的一些开发
当创建一个脚本或配置文件的时候：
make dist
则形成一个.gz的压缩包，但刚才创建的脚本或配置文件并没有加入，于是：
EXTRA_DIST = conf/config.cfg
script/example.sh
即可将脚本或配置文件放入到压缩包中；
若在多层目录上的时候，还可以使用宏SUBDIRS指定内部编译的顺序（包括当前目录），比如：
SUBDIRS = util /
thread /
. /
log
/
common
在编译系统make的时候，会严格按照顺序进行。
提供外部开发
如果工程完成了，别人想使用上面的库文件进行二次开发，该如何做呢？
libcpthreadincludedir = $(includedir)/@PACKAGE_NAME@/util/thread
libcpthreadinclude_HEADERS = thread.h
这样在编译系统make install的时候，会将头文件安装到上面指定的目录下，别人依照上面的build系统继续下面的build了。
交叉编译工具链作为嵌入式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-cygwinTARGET=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.oglibc已经不再支持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 -dumpspecs
sed -e 's@/lib(64)\?/ld@$(PREFTX)&@g'-e ,}/}}*cPP}$/{ns,$，-isystem $(PREFIX)/include,}"
>$SPECS
echo "New specs file is: $SPECS"
unset SPECS
测试调整后工具链:
echo 'main(川’>dummy.c
arm-linux-gcc
-B/cross-root/arm-linux/lib dummy.c
readelf -1 a.out I grep’:/cross-roobarm-linux'
调整正确的输出结果:
[Requesting program interpreter: /tools/lib/ld-linux.so.2j
一切正确后删除测试程序:
rm -v dummy.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(){}’>dummy.c
arm-linux-gcc -o dummy.exe dummy.c
file dummy.exe
运行正常的结果:
dummy.exe: ELF 32-bit LSB executable, ARM, version 1,for GNU/Linux 2.6.22, dynamically linked (uses shared libs),not stripped.
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）