C太厉害的Verilog会学不好

Verilog的优点是让你不用再花时间去学习一个新的语言（如VHDL），但缺点
是很容易用C的思维去写Verilog而不自知，因为代码实在太像了。

Verilog只是语法跟C相似，但观念却是硬件电路的概念。

主要的区别有：

1. C语言靠位置先后决定执行顺序；而Verilog却靠时钟来分先后，跟语句位置先后毫无关系。

如以下的Verilog:
  always@(posedge clk) begin
  e <= a & b;
  f <= c & d;
  end

虽然看起来是 e <= a & b; 在 f <= c & d;前面，但实际e和f并没有先后之分，是并行的。

2. 硬件要循序，要靠clock和FSM
或许你会说，『我的算法就是要循序一步一步的做，如C语言那样，那怎么办?』，若Verilog要这样，就得靠clock并且搭配FSM，当一个state完成后，进入下一个state，这样就能依照clock的进行，而达成循序的要求。

3.Verilog程序代码没有先后之分
除了blocking assignment有先后执行顺序，而nonblocking assignment同时执行外，Verilog的程序没有前后顺序之分，所以才称为硬件『描述』语言，而非硬件『程序』语言，先写的不代表先执行，后写的也不代表后执行，只是代表硬件的架构的描述，也就是说，将原来的电路图，变成文字描述而已。

4.多用RTL Viewer和ModelSim观察自己写的code
Verilog写法小小的差异，合成出来的硬件就可能有天壤之别，多用RTL Viewer观察合成出来的硬件是否和自己预期的一样，并多用ModelSim观察跑出来的波形，这样会增加你对Verilog的掌握度。

Conclusion
很多人学了Verilog，还是把它当C语言写，事实上他们只是语法类似，但背后的思维并不一样，唯有『心中有硬件』，才能设计出好的电路。

正在读的书：
王钿、卓兴旺 2007，基于Verilog HDL的数字应用设计，国防工业出版社

modelsim的一些常用命令

vlib work 建库
vmap work work 映射
vlog div.v tdiv.v 编译verilog写的代码
vcom div.vhl tdiv.vhl 编译vhdl 写的代码
vsim work.module 仿真相应模块
view wave/dataflow 显示波形窗口/数据流窗口
restart -f
run -all
quit -sim 退出仿真
pwd
cd
add wave /tdiv/* 把tdiv中的所有信号都加到wave波形图中

当然在modelsim中也可以用批处理文件，比如有一批处理文件file.do,则可用如下命令来调用它
do file.do

关于do文件的编写，有一个快速学习的好方法：
你执行的每一步鼠标点击or选择操作，在modelsim的命令行都有相应的代码输
出，你可以仿照写出正确的do文件。

(转)永远不要因为工作不好而辞职

其中的两句话很值得分享：

永远不要因为这个工作不好而辞职。一定要因为另一个工作更好而辞职。

人所拥有的「最后的」（last）自由是，我们可以选择我们的态度。

有一位老人，独自住在家里。他的儿女轮流回来照顾他。后来觉得最好还是住到老人院去比较好，因为他的眼睛已经完全看不见了。

迁入老人院的那一天，服务员牵着他的手告诉他，房间的样子，墙上的壁画，窗户外面是一大片草地，还有水池，这位老人回答说，真的好美，我想我在这里会很开心。服务员瞪着他，一脸讶异的说，你什么都看不见，你怎么知道美不美呢？

讲到这里，你大概已经知道这故事想要说的是什么了？

我们比那位老人的情况好多了。我们每天早上起来的时候有没有这么振奋，这么积极？

办公室里的事好像永远都做不完。烦恼的事不知道为什么总是那么多。房子、车子、小孩的学业，今天的早饭该吃什么，这些事从未间断过，就待会儿出
门，从车子开出去到抵达停车场，至少会发三次火：有人换车道没打信号灯；某段路塞车因为有人在路边并排停车；再有就是乱按喇叭。

想到这里，怪不得我们真的要做一选择。选择今天我要找到美好的事，还是要专注于烦恼的事。我们要选择感恩、宽容，抑或是要让抱怨、愤怒来折磨我。我们甚至可以在今天选择关心他人，对他人感兴趣的机会，而不要让冷漠习惯性的在心头。

30年前，我对当时的工作非常不满，时常抱怨，也多次口头叫嚷要辞职。有一天一位其它部门的年长主管跟我说，永远不要因为这个工作不好而辞职。一定要因为另一个工作更好而辞职。

这二句话对我很重要。影响也很大。卅年后的今天，回想起来，他说的真的很有道理。

现在的公司制度不好，下一个工作机构的体制多半也有缺陷。现在的公司不公平，谁能保证新的公司一切都很合理公道。现在的公司有派系，天知道多少公司有同样的权力斗争问题。跟现在的主管处不好，新工作的主管就一定处得好吗？

因而换工作不是解决办法。

根本的办法是改变态度。曾在集中营里住过，遭受过人类最悲惨的折磨的奥地利心理学家Victor
Frankel就认为，人所拥有的「最后的」（last）自由是，我们可以选择我们的态度。遭遇同样的打击，有的人选择的是绝望，有的人却选择了希望。

朋友，你选择的是什么？你准备怎样过这一天？

ARM，DSP，FPGA，CPLD,SOPC差别

FPGA和CPLD都是可编程逻辑器件，都可以用VHDL或verilog
HDL来编程，一般CPLD使用乘积项技术，粒度粗些；FPGA使用查找表技术，粒度细些，适用触发器较多的逻辑。其实多数时候都忽略它们的差异，

一般在设计ASIC芯片时要用FPGA验证，然后再把VHDL等程序映射为固定的版图，制作ASIC芯片，
在设计VHDL程序时，有可能要使用C仿真。

SOC就是单片系统，主要是器件太多设计复杂，成本高，可靠性差等缺点，所以单片系统是一个发展趋势。

SOPC就是可编程芯片系统，就是可以用FPGA/CPLD实现一个单片系统，譬如altera的Nios软核处理器嵌入到Stratix中。

●FPGA与CPLD的区别

系统的比较：
ＦＰＧＡ和ＣＰＬＤ都是可编程ＡＳＩＣ器件,有很多共同特点,但由于ＣＰＬＤ和ＦＰＧＡ结构上的差异,具有各自的特点:
①ＣＰＬＤ更适合完成各种算法和组合逻辑,ＦＰ
ＧＡ更适合于完成时序逻辑。换句话说,ＦＰＧＡ更适合于触发器丰富的结构,而ＣＰＬＤ更适合于触发器有限而乘积项丰富的结构。

②ＣＰＬＤ的连续式布线结构决定了它的时序延迟是均匀的和可预测的,而ＦＰＧＡ的分段式布线结构决定了其延迟的不可预测性。

③在编程上ＦＰＧＡ比ＣＰＬＤ具有更大的灵活性。ＣＰＬＤ通过修改具有固定内连电路的逻辑功能来编程,ＦＰＧＡ主要通过改变内部连线的布线来编程;ＦＰ
ＧＡ可在逻辑门下编程,而ＣＰＬＤ是在逻辑块下编程。

④ＦＰＧＡ的集成度比ＣＰＬＤ高,具有更复杂的布线结构和逻辑实现。

⑤ＣＰＬＤ比ＦＰＧＡ使用起来更方便。ＣＰＬＤ的编程采用Ｅ2ＰＲＯＭ或ＦＡＳＴＦＬＡＳＨ技术,无需外部存储器芯片,使用简单。而ＦＰＧＡ的编程信息需存放在外部存储器上,使用方法复杂。

⑥ＣＰＬＤ的速度比ＦＰＧＡ快,并且具有较大的时间可预测性。这是由于ＦＰＧＡ是门级编程,并且ＣＬＢ之间采用分布式互联,而ＣＰＬＤ是逻辑块级编程,并且其逻辑块之间的互联是集总式的。

⑦
在编程方式上,ＣＰＬＤ主要是基于Ｅ2ＰＲＯＭ或ＦＬＡＳＨ存储器编程,编程次数可达1万次,优点是系统断电时编程信息也不丢失。ＣＰＬＤ又可分为在编程
器上编程和在系统编程两类。ＦＰＧＡ大部分是基于ＳＲＡＭ编程,编程信息在系统断电时丢失,每次上电时,需从器件外部将编程数据重新写入ＳＲＡＭ中。其优
点是可以编程任意次,可在工作中快速编程,从而实现板级和系统级的动态配置。

⑧ＣＰＬＤ保密性好,ＦＰＧＡ保密性差。

⑨一般情况下,ＣＰＬＤ的功耗要比ＦＰＧＡ大,且集成度越高越明显。
随
著复杂可编程逻辑器件(CPLD)密度的提高,数字器件设计人员在进行大型设计时,既灵活又容易,而且产品可以很快进入市场。许多设计人员已经感受到
CPLD容易使用、时序可预测和速度高等优点,然而,在过去由于受到CPLD密度的限制,他们只好转向FPGA和ASIC。现在,设计人员可以体会到密度
高达数十万门的CPLD所带来的好处。
CPLD
结构在一个逻辑路径上采用1至16个乘积项,因而大型复杂设计的运行速度可以预测。因此,原有设计的运行可以预测,也很可靠,而且修改设计也很容易。
CPLD在本质上很灵活、时序简单、路由性能极好,用户可以改变他们的设计同时保持引脚输出不变。与FPGA相比,CPLD的I/O更多,尺寸更小。

如
今,通信系统使用很多标准,必须根据客户的需要配置设备以支持不同的标准。CPLD可让设备做出相应的调整以支持多种协议,并随著标准和协议的演变而改变
功能。这为系统设计人员带来很大的方便,因为在标准尚未完全成熟之前他们就可以著手进行硬件设计,然后再修改代码以满足最终标准的要求。CPLD的速度和
延迟特性比纯软件方案更好,它的NRE费用低於ASIC,更灵活,产品也可以更快入市。CPLD可编程方案的优点如下：
●逻辑和存储器资源丰富(Cypress Delta39K200的RAM超过480 Kb)
●带冗余路由资源的灵活时序模型
●改变引脚输出很灵活
●可以装在系统上后重新编程
●I/O数目多
●具有可保证性能的集成存储器控制逻辑
●提供单片CPLD和可编程PHY方案
由于有这些优点,设计建模成本低,可在设计过程的任一阶段添加设计或改变引脚输出,可以很快上市
CPLD的结构
CPLD是属於粗粒结构的可编程逻辑器件。它具有丰富的逻辑资源(即逻辑门与寄存器的比例高)和高度灵活的路由资源。CPLD的路由是连接在一起的,而FPGA的路由是分割开的。FPGA可能更灵活,但包括很多跳线,因此速度较CPLD慢。
CPLD以群阵列（array of
clusters）的形式排列,由水平和垂直路由通道连接起来。这些路由通道把信号送到器件的引脚上或者传进来,并且把CPLD内部的逻辑群连接起来。

CPLD之所以称作粗粒,是因为,与路由数量相比,逻辑群要大得到。CPLD的逻辑群比FPGA的基本单元大得多,因此FPGA是细粒的。
CPLD的功能块
CPLD最基本的单元是宏单元。一个宏单元包含一个寄存器(使用多达16个乘积项作为其输入)及其它有用特性。
因为每个宏单元用了16个乘积项,因此设计人员可部署大量的组合逻辑而不用增加额外的路径。这就是为何CPLD被认为是"逻辑丰富"型的。

宏单元以逻辑模块的形式排列(LB),每个逻辑模块由16个宏单元组成。宏单元执行一个AND操作,然后一个OR操作以实现组合逻辑。

每个逻辑群有8个逻辑模块,所有逻辑群都连接到同一个可编程互联矩阵。
每个群还包含两个单端口逻辑群存储器模块和一个多端口通道存储器模块。前者每模块有8,192b存储器,后者包含4,096b专用通信存储器且可配置为单端口、多端口或带专用控制逻辑的FIFO。
CPLD有什么好处？
I/O数量多
CPLD的好处之一是在给定的器件密度上可提供更多的I/O数,有时甚至高达70%。
时序模型简单
CPLD优于其它可编程结构之处在于它具有简单且可预测的时序模型。这种简单的时序模型主要应归功于CPLD的粗粒度特性。
CPLD可在给定的时间内提供较宽的相等状态,而与路由无关。这一能力是设计成功的关键,不但可加速初始设计工作,而且可加快设计调试过程。
粗粒CPLD结构的优点
CPLD是粗粒结构,这意味著进出器件的路径经过较少的开关,相应地延迟也小。因此,与等效的FPGA相比,CPLD可工作在更高的频率,具有更好的性能。
CPLD的另一个好处是其软件编译快,因为其易于路由的结构使得布放设计任务更加容易执行。

细粒FPGA结构的优点
FPGA是细粒结构,这意味著每个单元间存在细粒延迟。如果将少量的逻辑紧密排列在一起,FPGA的速度相当快。然而,随著设计密度的增加,信号不得不通过许多开关,路由延迟也快速增加,从而削弱了整体性能。CPLD的粗粒结构却能很好地适应这一设计布局的改变。

灵活的输出引脚
CPLD的粗粒结构和时序特性可预测,因此设计人员在设计流程的后期仍可以改变输出引脚,而时序仍保持不变。
新的CPLD封装
CPLD有多种密度和封装类型,包括单芯片自引导方案。自引导方案在单个封装内集成了FLASH存储器和CPLD,无须外部引导单元,从而可降低设计复杂性并节省板空间。在给定的封装尺寸内,有更高的器件密度共享引脚输出。这就为设计人员提供了"放大"设计的便利,而无须更改板上的引脚输出。

●Arm是一种嵌入式芯片，比单片机功能强，可以针对需要增加外设。类似于通用cpu，但是不包括桌面计算机。

DSP主要用来计算，计算功能很强悍，一般嵌入式芯片用来控制，而DSP用来计算，譬如一般手机有一个arm芯片，主要用来跑界面，应用程序，DSP可能有两个，adsp,mdsp，或一个，主要是加密解密，调制解调等。

●ARM其实就是一个知识产权，ARM公司本身不生产芯片，但是向其它公司提供授权。

alterA有嵌入ARM内核的SOPC芯片。

如果自己设计一个ARM芯片，显然是不大可能的，即使设计出来嵌入式芯片，也不能叫ARM。

当然用FPGA设计简单的处理器芯片应该还是有可能的，好象外国大学都有这样的课程设计，有很多书籍介绍设计简单的处理器芯片的。处理器芯片主要就是把指令译码，分派给不同的功能部件来执行工作，如果加流水线，预测执行以及存储器、外设等等功能，应该工作量很大的。

●其实象工作量特别大的运算，一般还是用FPGA/ASIC来实现的，如在手机基带芯片中，码片级的运算，一般是用FPGA/ASIC，而比特级的运算，应该用DSP实现的多

关于u-boot代码结构

1. u-boot 介绍
u-boot 是一个open source 的bootloader。u-boot 是在ppcboot 以及armboot
的基础上发展而来，已经在许多嵌入式系统开发过程中被采用。由于其开发源代码，其支持的开发板众多。

2. start.S 代码结构
1) 定义入口
一个可执行的Image
必须有一个入口点并且只能有一个唯一的全局入口，通常这个入口放在Rom(flash)的0x0
地址。例如start.S 中的
.globl _start
_start:
值得注意的是你必须告诉编译器知道这个入口，这个工作主要是修改连接器脚本文件（lds）。
2) 设置异常向量(Exception Vector)
异常向量表，也可称为中断向量表，必须是从0
地址开始，连续的存放。如下面的就包括了复位(reset),未定义处理（undef）,软件中断(SWI),预去指令错误(Pabort),数据错误
(Dabort),保留，以及IRQ,FIQ 等。注意这里的值必须与uClinux 的vector_base
一致。这就是说如果uClinux
中vector_base(include/armnommu/proc-armv/system.h)定义为0x0c00
0000,则HandleUndef 应该在
0x0c00 0004。
b reset //for debug
ldr pc,=HandleUndef
ldr pc,=HandleSWI
ldr pc,=HandlePabort
ldr pc,=HandleDabort
b .
ldr pc,=HandleIRQ
ldr pc,=HandleFIQ
ldr pc,=HandleEINT0 /*mGA H/W interrupt vector table*/
ldr pc,=HandleEINT1
ldr pc,=HandleEINT2
ldr pc,=HandleEINT3
ldr pc,=HandleEINT4567
ldr pc,=HandleTICK /*mGA*/
b .
b .
ldr pc,=HandleZDMA0 /*mGB*/
ldr pc,=HandleZDMA1
ldr pc,=HandleBDMA0
ldr pc,=HandleBDMA1
ldr pc,=HandleWDT
ldr pc,=HandleUERR01 /*mGB*/
b .
b .
ldr pc,=HandleTIMER0 /*mGC*/
ldr pc,=HandleTIMER1
ldr pc,=HandleTIMER2
ldr pc,=HandleTIMER3
ldr pc,=HandleTIMER4
ldr pc,=HandleTIMER5 /*mGC*/
b .
b .
ldr pc,=HandleURXD0 /*mGD*/
ldr pc,=HandleURXD1
ldr pc,=HandleIIC
ldr pc,=HandleSIO
ldr pc,=HandleUTXD0
ldr pc,=HandleUTXD1 /*mGD*/
b .
b .
ldr pc,=HandleRTC /*mGKA*/
b .
b .
b .
b .
b . /*mGKA*/
b .
b .
ldr pc,=HandleADC /*mGKB*/
b .
b .
b .
b .
b . /*mGKB*/
b .
b .
ldr pc,=EnterPWDN
作为对照：请看以上标记的值：
.equ HandleReset, 0xc000000
.equ HandleUndef,0xc000004
.equ HandleSWI, 0xc000008
.equ HandlePabort, 0xc00000c
.equ HandleDabort, 0xc000010
.equ HandleReserved, 0xc000014
.equ HandleIRQ, 0xc000018
.equ HandleFIQ, 0xc00001c
/*the value is different with an address you think it may be.
*IntVectorTable */
.equ HandleADC, 0xc000020
.equ HandleRTC, 0xc000024
.equ HandleUTXD1, 0xc000028
.equ HandleUTXD0, 0xc00002c
.equ HandleSIO, 0xc000030
.equ HandleIIC, 0xc000034
.equ HandleURXD1, 0xc000038
.equ HandleURXD0, 0xc00003c
.equ HandleTIMER5, 0xc000040
.equ HandleTIMER4, 0xc000044
.equ HandleTIMER3, 0xc000048
.equ HandleTIMER2, 0xc00004c
.equ HandleTIMER1, 0xc000050
.equ HandleTIMER0, 0xc000054
.equ HandleUERR01, 0xc000058
.equ HandleWDT, 0xc00005c
.equ HandleBDMA1, 0xc000060
.equ HandleBDMA0, 0xc000064
.equ HandleZDMA1, 0xc000068
.equ HandleZDMA0, 0xc00006c
.equ HandleTICK, 0xc000070
.equ HandleEINT4567, 0xc000074
.equ HandleEINT3, 0xc000078
.equ HandleEINT2, 0xc00007c
.equ HandleEINT1, 0xc000080
.equ HandleEINT0, 0xc000084
3) 初始化CPU 相关的pll,clock,中断控制寄存器
依次为关闭watch dog timer,关闭中断，设置LockTime，PLL(phase lock
loop),以及时钟。
这些值（除了LOCKTIME）都可从Samsung 44b0 的手册中查到。
ldr r0,WTCON //watch dog disable
ldr r1,=0x0
str r1,[r0]
ldr r0,INTMSK
ldr r1,MASKALL //all interrupt disable
str r1,[r0]
/*****************************************************
* Set clock control registers *
*****************************************************/
ldr r0,LOCKTIME
ldr r1,=800 // count = t_lock * Fin (t_lock=200us, Fin=4MHz) = 800
str r1,[r0]
ldr r0,PLLCON /*temporary setting of PLL*/
ldr r1,PLLCON_DAT /*Fin=10MHz,Fout=40MHz or 60MHz*/
str r1,[r0]
ldr r0,CLKCON
ldr r1,=0x7ff8 //All unit block CLK enable
str r1,[r0]
4) 初始化内存控制器
内存控制器，主要通过设置13 个从1c80000 开始的寄存器来设置，包括总线宽度，
8 个内存bank，bank 大小，sclk,以及两个bank mode。
/*****************************************************
* Set memory control registers *
*****************************************************/
memsetup:
adr r0,SMRDATA
ldmia r0,{r1-r13}
ldr r0,=0x01c80000 //BWSCON Address
stmia r0,{r1-r13}
5) 将rom 中的程序复制到RAM 中
首先利用PC 取得bootloader 在flash
的起始地址，再通过标号之差计算出这个程序代
码的大小。这些标号，编译器会在连接（link）的时候生成正确的分布的值。取得正
确信息后，通过寄存器(r3 到r10)做为复制的中间媒介，将代码复制到RAM 中。
relocate:
/*
* relocate armboot to RAM
*/
adr r0, _start /* r0 <- current position of code */
ldr r2, _armboot_start
ldr r3, _armboot_end
sub r2, r3, r2 /* r2 <- size of armboot */
ldr r1, _TEXT_BASE /* r1 <- destination address */
add r2, r0, r2 /* r2 <- source end address */
/*
* r0 = source address
* r1 = target address
* r2 = source end address
*/
copy_loop:
ldmia r0!, {r3-r10}
stmia r1!, {r3-r10}
cmp r0, r2
ble copy_loop
6) 初始化堆栈
进入各种模式设置相应模式的堆栈。
InitStacks:
/*Don't use DRAM,such as stmfd,ldmfd......
SVCstack is initialized before*/
mrs r0,cpsr
bic r0,r0,#0X1F
orr r1,r0,#0xDB /*UNDEFMODE|NOINT*/
msr cpsr,r1 /*UndefMode*/
ldr sp,UndefStack
orr r1,r0,#0XD7 /*ABORTMODE|NOINT*/
msr cpsr,r1 /*AbortMode*/
ldr sp,AbortStack
orr r1,r0,#0XD2 /*IRQMODE|NOINT*/
msr cpsr,r1 /*IRQMode*/
ldr sp,IRQStack
orr r1,r0,#0XD1 /*FIQMODE|NOINT*/
msr cpsr,r1 /*FIQMode*/
ldr sp,FIQStack
bic r0,r0,#0XDF /*MODEMASK|NOINT*/
orr r1,r0,#0X13
msr cpsr,r1 /*SVCMode*/
ldr sp,SVCStack
7) 转到RAM 中执行
使用指令ldr,pc,RAM 中C 函数地址就可以转到RAM 中去执行。
5. 系统初始化部分
1. 串口部分
串口的设置主要包括初始化串口部分，值得注意的串口的Baudrate 与时钟MCLK
有很大关系，是通过：rUBRDIV0=( (int)(MCLK/16./(gd ->baudrate) + 0.5) -1
)计算得出。这可以在手册中查到。其他的函数包括发送，接收。这个时候没有中断，是通过循环等待来判断是否动作完成。
例如，接收函数：
while(!(rUTRSTAT0 & 0x1)); //Receive data read
return RdURXH0();
2. 时钟部分
实现了延时函数udelay。
这里的get_timer 由于没有使用中断，是使用全局变量来累加的。
3. flash 部分
flash 作为内存的一部分，读肯定没有问题，关键是flash 的写部分。
Flash 的写必须先擦除，然后再写。
unsigned long flash_init (void)
{
int i;
u16 manId,devId;
//first we init it as unknown,even if you forget assign it below,it's not
a problem
for (i=0; i < CFG_MAX_FLASH_BANKS; ++i){
flash_info[i].flash_id = FLASH_UNKNOWN;
flash_info[i].sector_count=CFG_MAX_FLASH_SECT;
}
/*check manId,devId*/
_RESET();
_WR(0x555,0xaa);
_WR(0x2aa,0x55);
_WR(0x555,0x90);
manId=_RD(0x0);
_WR(0x555,0xaa);
_WR(0x2aa,0x55);
_WR(0x555,0x90);
devId=_RD(0x1);
_RESET();
printf("flashn");
printf("Manufacture ID=%4x(0x0004), Device ID(0x22c4)=%4xn",manId,devId);
if(manId!=0x0004 && devId!=0x22c4){
printf("flash check faliluren");
return 0;
}else{
for (i=0; i < CFG_MAX_FLASH_BANKS; ++i){
flash_info[i].flash_id=FLASH_AM160T;/*In fact it is fujitu,I only don't
want to
modify common files*/
}
}
/* Setup offsets */
flash_get_offsets (CFG_FLASH_BASE, &flash_info[0]);
/* zhangyy comment
#if CFG_MONITOR_BASE >= CFG_FLASH_BASE
//onitor protection ON by default
flash_protect(FLAG_PROTECT_SET,
CFG_MONITOR_BASE,
CFG_MONITOR_BASE+monitor_flash_len-1,
&flash_info[0]);

(转)BusyBox 简化嵌入式 Linux 系统

来源：http://www.xxlinux.com/linux/article/development/embed/20080128/13696.html

BusyBox 简化嵌入式 Linux 系统

BusyBox 是很多标准 Linux® 工具的一个单个可执行实现。BusyBox
包含了一些简单的工具，例如 cat 和
echo，还包含了一些更大、更复杂的工具，例如 grep、find、mount 以及
telnet（不过它的选项比传统的版本要少）；有些人将 BusyBox 称为 Linux
工具里的瑞士军刀。本文将探索 BusyBox
的目标，它是如何工作的，以及为什么它对于内存有限的环境来说是如此重要。

BusyBox 的诞生

BusyBox 最初是由 Bruce Perens 在 1996 年为 Debian GNU/Linux
安装盘编写的。其目标是在一张软盘上创建一个可引导的 GNU/Linux
系统，这可以用作安装盘和急救盘。一张软盘可以保存大约 1.4-1.7MB
的内容，因此这里没有多少空间留给 Linux 内核以及相关的用户应用程序使用。

BusyBox 揭露了这样一个事实：很多标准 Linux
工具都可以共享很多共同的元素。例如，很多基于文件的工具（比如 grep 和
find）都需要在目录中搜索文件的代码。当这些工具被合并到一个可执行程序中时，它们就可以共享这些相同的元素，这样可以产生更小的可执行程序。实际
上， BusyBox 可以将大约 3.5MB 的工具包装成大约 200KB
大小。这就为可引导的磁盘和使用 Linux
的嵌入式设备提供了更多功能。我们可以对 2.4 和 2.6 版本的 Linux 内核使用
BusyBox。

BusyBox 是如何工作的？

为了让一个可执行程序看起来就像是很多可执行程序一样，BusyBox 为传递给 C 的
main 函数的参数开发了一个很少使用的特性。回想一下 C 语言的 main
函数的定义如下：

清单 1. C 的 main 函数
int main( int argc, char *argv[] )

在这个定义中，argc 是传递进来的参数的个数（参数数量），而 argv
是一个字符串数组，代表从命令行传递进来的参数（参数向量）。argv 的索引 0
是从命令行调用的程序名。

清单 2 给出的这个简单 C 程序展示了 BusyBox 的调用。它只简单地打印 argv
向量的内容。

清单 2. BusyBox 使用 argv[0] 来确定调用哪个应用程序
// test.c
#include <stdio.h>
int main( int argc, char *argv[] )
{
int i;
for (i = 0 ; i < argc ; i++) {
printf("argv[%d] = %s\n", i, argv[i]);
}
return 0;
}

调用这个程序会显示所调用的第一个参数是该程序的名字。我们可以对这个可执行程序重新进行命名，此时再调用就会得到该程序的新名字。另外，我们可以创建一个到可执行程序的符号链接，在执行这个符号链接时，就可以看到这个符号链接的名字。

清单 3. 在使用新命令更新 BusyBox 之后的命令测试
$ gcc -Wall -o test test.c
$ ./test arg1 arg2
argv[0] = ./test
argv[1] = arg1
argv[2] = arg2
$ mv test newtest
$ ./newtest arg1
argv[0] = ./newtest
argv[1] = arg1
$ ln -s newtest linktest
$ ./linktest arg
argv[0] = ./linktest
argv[1] = arg

BusyBox 使用了符号链接以便使一个可执行程序看起来像很多程序一样。对于
BusyBox
中包含的每个工具来说，都会这样创建一个符号链接，这样就可以使用这些符号链接来调用
BusyBox 了。BusyBox 然后可以通过 argv[0] 来调用内部工具。

配置并编译 BusyBox

我 们可以从 BusyBox 的 Web 站点上下载最新版本的 BusyBox（请参看 参考资料
一节的内容）。与大部分开放源码程序一样，它是以一个压缩的 tarball
形式发布的，我们可以使用清单 4
给出的命令将其转换成源代码树。（如果我们下载的版本不是
1.1.1，那就请在这个命令中使用适当的版本号以及特定于这个版本号的命令。）

清单 4. 展开 BusyBox
$ tar xvfz busybox-1.1.1.tar.gz
$

结果会生成一个目录，名为 busybox-1.1.1，其中包含了 BusyBox
的源代码。要编译默认的配置（其中包含了几乎所有的内容，并禁用了调试功能），请使用
defconfig make 目标：

清单 5. 编译默认的 BusyBox 配置
$ cd busybox-1.1.1
$ make defconfig
$ make
$

结 果是一个相当大的 BusyBox
映像，不过这只是开始使用它的最简单的方法。我们可以直接调用这个新映像，这会产生一个简单的
Help
页面，里面包括当前配置的命令。要对这个映像进行测试，我们也可以对一个命令调用
BusyBox 来执行，如清单 6 所示。

清单 6. 展示 BusyBox 命令的执行和 BusyBox 中的 ash shell
$ ./busybox pwd
/usr/local/src/busybox-1.1.1
$ ./busybox ash
/usr/local/src/busybox-1.1.1 $ pwd
/usr/local/src/busybox-1.1.1
/usr/local/src/busybox-1.1.1 $ exit
$

在这个例子中，我们调用了 pwd（打印工作目录）命令，使用 BusyBox 进入了 ash
shell，并在 ash 中调用了 pwd。

手工配置

如 果您正在构建一个具有特殊需求的嵌入式设备，那就可以手工使用 menuconfig
make 目标来配置 BusyBox 的内容。如果您熟悉 Linux
内核的编译过程，就会注意到 menuconfig 与配置 Linux
内核的内容所使用的目标相同。实际上，它们都采用了相同的基于 ncurses
的应用程序。

使 用手工配置，我们可以指定在最终的 BusyBox 映像中包含的命令。我们也可以对
BusyBox 环境进行配置，例如包括对 NSA（美国国家安全代理）的安全增强
Linux（SELinux），指定要使用的编译器（用来在嵌入式环境中进行交叉编译）以及
BusyBox 应该静态编译还是动态编译。使用 menuconfig可以为 BusyBox
配置的不同类型的应用程序（applet）。

多体系结构支持

可以简单地为 BusyBox 指定交叉编译器意味着我们可以为很多体系结构编译
BusyBox。要为您的目标体系结构编译
BusyBox，我们需要一个交叉编译器和一个已经为特定目标体系结构编译好的 C
库（uClibc 或 glibc）。

要手工配置 BusyBox，请使用下面的命令：

清单 7. 手工配置 BusyBox
$ make menuconfig
$ make
$

这为我们提供了可以调用的 BusyBox 的二进制文件。下一个步骤是围绕 BusyBox
构建一个环境，包括将标准 Linux 命令重定向到 BusyBox
二进制文件的符号链接。我们可以使用下面的命令简单地完成这个过程：

清单 8. 构建 BusyBox 环境$ make install
$

默 认情况下，这会创建一个新的本地子目录 _install，其中包含了基本的 Linux
环境。在这个根目录中，您会找到一个链接到 BusyBox 的 linuxrc 程序。这个
linuxrc
程序在构建安装盘或急救盘（允许提前进行模块化的引导）时非常有用。同样是在这个根目录中，还有一个包含操作系统二进制文件的
/sbin 子目录。还有一个包含用户二进制文件的 /bin
目录。在构建软盘发行版或嵌入式初始 RAM 磁盘时，我们可以将这个 _install
目录迁移到目标环境中。我们还可以使用 make 程序的 PREFIX
选项将安装目录重定向到其他位置。例如，下面的代码就使用 /tmp/newtarget
根目录来安装这些符号链接，而不是使用 ./_install 目录：

清单 9. 将符号链接安装到另外一个目录中$ make PREFIX=/tmp/newtarget install
$

使 用 install make 目标创建的符号链接都来自于 busybox.links
文件。这个文件是在编译 BusyBox
时创建的，它包含了已经配置的命令清单。在执行 install 时，就会检查
busybox.links 文件确定要创建的符号链接。

到 BusyBox 的命令行链接也可以使用 BusyBox
在运行时动态创建。CONFIG_FEATURE_INSTALLER
选项就可以启用这个特性，在运行时可以这样执行：

清单 10. 在运行时创建命令链接$ ./busybox --install -s
$

-s 选项强制创建这些符号链接（否则就创建硬链接）。这个选项要求系统中存在
/proc 文件系统。

BusyBox 编译选项

BusyBox 包括了几个编译选项，可以帮助为我们编译和调试正确的 BusyBox。

表 1. 为 BusyBox 提供的几个 make 选项

make目标 说明help 显示 make 选项的完整列表
defconfig 启用默认的（通用）配置
allnoconfig 禁用所有的应用程序（空配置）
allyesconfig 启用所有的应用程序（完整配置）
allbareconfig 启用所有的应用程序，但是不包括子特性
config 基于文本的配置工具
menuconfig N-curses（基于菜单的）配置工具
all 编译 BusyBox 二进制文件和文档（./docs）
busybox 编译 BusyBox 二进制文件
clean 清除源代码树
distclean 彻底清除源代码树
sizes 显示所启用的应用程序的文本/数据大小

在定义配置时，我们只需要输入 make 就可以真正编译 BusyBox
二进制文件。例如，要为所有的应用程序编译 BusyBox，我们可以执行下面的命令：

清单 11. 编译 BusyBox 二进制程序$ make allyesconfig
$ make
$

压缩 BusyBox

如果您非常关心对 BusyBox 映像的压缩，就需要记住两件事情：

1.
永远不要编译为静态二进制文件（这会将所有需要的库都包含到映像文件中）。相反，如果我们是编译为一个共享映像，那么它会使用其他应用程序使用的库（例如
/lib/libc.so.X）。

2. 使用 uClibc 进行编译，这是一个对大小进行过优化的 C
库，它是为嵌入式系统开发的；而不要使用标准的 glibc （GNU C 库）来编译。

BusyBox 命令中支持的选项

BusyBox
中的命令并不支持所有可用选项，不过这些命令都包含了常用的选项。如果我们需要知道一个命令可以支持哪些选项，可以使用
--help 选项来调用这个命令，如清单 12 所示。

清单 12. 使用 --help 选项调用命令$ ./busybox wc --help
BusyBox v1.1.1 (2006.04.09-15:27+0000) multi-call binary
Usage: wc [OPTION]... [FILE]...
Print line, word, and byte counts for each FILE, and a total line if
more than one FILE is specified. With no FILE, read standard input.
Options:
-c print the byte counts
-l print the newline counts
-L print the length of the longest line
-w print the word counts
$

这些特定的数据只有在启用了 CONFIG_FEATURE_VERBOSE_USAGE
选项时才可以使用。如果没有这个选项，我们就无法获得这些详细数据，但是这样可以节省大约
13 KB 的空间。

向 BusyBox 中添加新命令

向 BusyBox
添加一个新命令非常简单，这是因为它具有良好定义的体系结构。第一个步骤是为新命令的源代码选择一个位置。我们要根据命令的类型（网络，shell
等）来选择位置，并与其他命令保持一致。这一点非常重要，因为这个新命令最终会在
menuconfig 的配置菜单中出现（在下面的例子中，是 Miscellaneous Utilities
菜单）。

对于这个例子来说，我将这个新命令称为 newcmd，并将它放到了 ./miscutils
目录中。这个新命令的源代码如清单 13 所示。

清单 13. 集成到 BusyBox 中的新命令的源代码#include "busybox.h"
int newcmd_main( int argc, char *argv[] )
{
int i;
printf("newcmd called:\n");
for (i = 0 ; i < argc ; i++) {
printf("arg[%d] = %s\n", i, argv[i]);
}
return 0;
}

接下来，我们要将这个新命令的源代码添加到所选子目录中的 Makefile.in
中。在本例中，我更新了 ./miscutils/Makefile.in
文件。请按照字母顺序来添加新命令，以便维持与现有命令的一致性：

清单 14. 将命令添加到 Makefile.in 中MISCUTILS-$(CONFIG_MT) += mt.o
MISCUTILS-$(CONFIG_NEWCMD) += newcmd.o
MISCUTILS-$(CONFIG_RUNLEVEL) += runlevel.o

接下来再次更新 ./miscutils
目录中的配置文件，以便让新命令在配置过程中是可见的。这个文件名为
Config.in，新命令是按照字母顺序添加的：

清单 15. 将命令添加到 Config.in 中config CONFIG_NEWCMD
bool "newcmd"
default n
help
newcmd is a new test command

这 个结构定义了一个新配置项（通过 config
关键字）以及一个配置选项（CONFIG_NEWCMD）。新命令可以启用，也可以禁用，因此我们对配置的菜单属性使用了
bool （Boolean）值。这个命令默认是禁用的（n 表示
No），我们可以最后放上一个简短的 Help 描述。在源代码树的
./scripts/config/Kconfig-language.txt
文件中，我们可以看到配置语法的完整文法。

接下来需要更新 ./include/applets.h
文件，使其包含这个新命令。将下面这行内容添加到这个文件中，记住要按照字母顺序。维护这个次序非常重要，否则我们的命令就会找不到。

清单 16. 将命令添加到 applets.h 中USE_NEWCMD(APPLET(newcmd, newcmd_main,
_BB_DIR_USER_BIN, _BB_SUID_NEVER))

这定义了命令名（newcmd），它在 Busybox
源代码中的函数名（newcmd_main），应该在哪里会为这个新命令创建链接（在这种情况中，它在
/usr/bin 目录中），最后这个命令是否有权设置用户 id（在本例中是 no）。

倒数第二个步骤是向 ./include/usage.h
文件中添加详细的帮助信息。正如您可以从这个文件的例子中看到的一样，使用信息可能非常详细。在本例中，我只添加了一点信息，这样就可以编译这个新命令了：

清单 17. 向 usage.h 添加帮助信息#define newcmd_trivial_usage "None"
#define newcmd_full_usage "None"

最后一个步骤是启用新命令（通过 make menuconfig，然后在 Miscellaneous
Utilities 菜单中启用这个选项）然后使用 make 来编译 BusyBox。

使用新的 BusyBox，我们可以对这个新命令进行测试，如清单 18 所示。

清单 18. 测试新命令$ ./busybox newcmd arg1
newcmd called:
arg[0] = newcmd
arg[1] = arg1
$ ./busybox newcmd --help
BusyBox v1.1.1 (2006.04.12-13:47+0000) multi-call binary

Usage: newcmd None

None

就是这样！BusyBox 开发人员开发了一个优秀但非常容易扩展的工具。

结束语

BusyBox 是为构建内存有限的嵌入式系统和基于软盘系统的一个优秀工具。BusyBox
通过将很多必需的工具放入一个可执行程序，并让它们可以共享代码中相同的部分，从而对它们的大小进行了很大程度的缩减，BusyBox
对于嵌入式系统来说是一个非常有用的工具，因此值得我们花一些时间进行探索。

(转)在 Linux 系统上源码安装 GTK+ 2.0

原文链接 http://bbs.chinaunix.net/viewthread.php?tid=882435

==================================================
Keywords: GTK+, Install, Linux, Source
Author: whyglinux (whyglinux AT hotmail DOT com)
Date: 2007-01-07
==================================================

目录

0. 前言
1. 二进制安装和源码安装
2. GTK+ 依赖软件包
3. 查看软件的版本号
4. 安装规划
4.1 系统上未安装 GTK+
4.2 系统上已安装 GTK+
5. 软件下载
6. 库的安装
6.1 安装顺序
6.2 安装过程
6.2.1 解包
6.2.2 配置
6.2.3 构建
6.2.4 安装
6.2.5 设置
6.2.5.1 搜索路径
6.2.5.2 编译和连接界面
6.2.5.3 pkg-config
6.2.5.4 GTK+ 及其依赖库的设置
6.2.5.4.1 以编译和连接为目的的设置
6.2.5.4.2 以连接和执行为目的的设置
6.3 其它库的安装
6.3.1 安装 Atk
6.3.2 安装 Cairo
6.3.3 安装 Pango
6.3.4 安装 Gtk+
7. 库的使用
7.1 库使用之前的设置
7.2 库文档

-----------------------------------------------------------------------------

0. 前言

GTK+ 2.0
依赖的软件包（程序和库）比较多，版本的更新也比较频繁，所以如果想从 GTK+
提供的源码软件包中构建一套较新或最新版本的 GTK+
库来使用的话，通常需要首先更新或者安装一系列新版本的依赖程序或库。同时，由于软件包之间存在着依赖关系，对软件包的版本和安装顺序都有一定的要求，一般还需要对安装后的库进行一些必要的设置才能使用库。因而，可以说源码安装
GTK+ 是一项不小的工程。如果没有源码安装 GTK+
的经验，在安装过程中很容易遇到一些问题。对于新手来说，出现了安装问题时却往往不知道如何去解决。

本文试图对 GTK+
的源码安装提供一套可行的解决方案，介绍一些安装和使用库方面的背景知识，对安装过程中容易出现问题的地方做了强调说明，以使安装过程能够顺利进行。这样，即使是一个从来没有安装过
GTK+ 的新手也能根据这里的说明顺利地安装上 GTK+。

如果你发现了本篇中的错误，或者对本文有什么感想或者建议，可通过 whyglinux
AT hotmail DOT com 邮箱和作者联系。

1. 二进制安装和源码安装

需要首先说明的的是：对于 Linux 系统、特别是较新版本的 Linux
系统来说，其发行版中已经包含了 GTK+
和所有的支撑软件，一般来说默认安装后就可以直接使用 GTK+
了。如果在安装的时候没有选择安装 GTK+，也可以用系统提供的安装工具将 GTK+
添加到系统中来，或者下载已经编译好的 GTK+ 进行版本升级。

上面的安装方式使用的是已经编译好的软件包。由于这种安装一般会自动解决各个软件包之间的依赖关系，进而安装或者更新相应的软件包，所以与源码安装方式相比，二进制包的安装节省了编译代码所需要的时间，避免了源码安装的种种繁琐易错之处，对于安装者的要求也较低，因此是安装
GTK+ 的首选方式。

二进制安装方式简单快捷，但也有其力所不及的地方：通常一个软件的二进制包的版本更新要落后于其最新版本，有些软件也可能没有二进制包提供。这样，要使用最新的版本很可能源码安装就是唯一可以选择的方式了。有时人们也想体验或学习
GTK+
的源码安装方式，毕竟在开源盛世的今天，对于程序员来说源码安装也是必须要过的一关。

2. GTK+ 依赖软件包

GTK+
的安装需要下面程序或者库的支持（可在列出的链接中找到各个软件包的下载地址）：

1. C 编译器（如 GCC。GCC 的网站）
2. X 窗口系统库（网站）
3. pkg-config 工具(网站)
4. GNU make 工具(网站)
5. JPEG、PNG 以及 TIFF 图形库（下载页面 的 GTK+ Source 中的
dependencies 目录）
6. FreeType（网站）
7. fontconfig 库（网站）
8. GNU libiconv 库（当系统上没有 iconv() 函数的时候需要）（网站）
9. GNU gettext 软件包（当系统上没有 gettext()
函数的时候需要）（[url=http://www.gnu.org/software/gettext/网站[/url]）
10. GLib 库（下载页面 的 GLib Source）
11. ATK 库（下载页面 的 GTK+ Source 中的 dependencies 目录）
12. Cairo 库（下载页面 的 GTK+ Source 中的 dependencies 目录）
13. Pango 库（下载页面 的 Pango Source）
14. GTK+ 库（下载页面 的 GTK+ Source）

目前（写此文时）最新的 GTK+ 是 2.10.6
版，我们就以这个版本为例介绍。当你看到这篇文章的时候，可能 GTK+
又有了新的版本，所以要注意下载安装新版本的软件包。

其中，以上 1～9 各项是一些比较通用的软件，和 GTK+
的关系也没有那么紧密－－它们不但被 GTK+
使用，也被其它程序或者库使用。即使系统上没有安装
GTK+，它们也可能已经在系统中存在了。

10～13 各项和 GTK+ 关系密切，更新也较快，通常一个 GTK+
的版本会依赖于这些库的一些特定的版本。由于这些原因，在本文中说明 GTK+
安装的时候认为 1～9 项已经安装好了，所以只涉及到 10～14
项的安装。也就是说，GTK+ 的安装实际上主要是 GLib、Atk、Cairo、Pango 和
Gtk+ 这五个库的安装。

当然，在你的系统 1～9
各项中也可能存在没有安装的情况，也可能存在由于版本过低从而使 GTK+
不能顺利安装的情况。当遇到这些情况的时候，应该参考各自的网站中的安装说明对软件进行安装或者升级。可以使用二进制包直接安装，也可以使用源码方式安装。在本文中对这些软件的安装将不再叙述。

根据经验，只要系统中已经有了 1～9 各项，而且系统也较新的话，为了安装 GTK+
一般没有必要把它们都升级到最新版本，除了其中的 pkg-config 工具。pkg-config
的变动较大，新版本的 GTK+ 的安装需要新版 pkg-config
的支持，否则可能会使安装过程失败。因此，要在安装 GTK+ 之前检查 pkg-config
的版本号。如果版本过低，一定要对它进行版本更新。至于 GTK+ 安装时对
pkg-config 的最低版本要求，可以在 GTK+ 下载目录的 dependencies
目录中找到对应的 pkg-config 软件包，从软件包上提供的版本信息中获得确认。

3. 查看软件的版本号

查看已经安装的软件的版本号的目的有二：

* 检查软件是否存在
*
获得软件的版本号，从中可以了解软件的新旧程度，是决定软件是否需要更新的依据

软件包大致可分为两种类型：程序和库。类型不同，查看版本号的方式也不同。

对于可运行的程序命令来说，查看版本号的方式是在执行命令后加上 --version
参数。例如，对于 pkg-config 来说，其过程是这样的：

$ pkg-config --version

上面的"$"符号表示命令行提示符。

注：你现在应该执行上面的命令查看 pkg-config
的版本号，并按照上面所述检查是否符合安装相应的 GTK+
的最低版本要求。如果不符合要求，在进行下面的 GTK+
及其依赖库的安装之前应该首先安装和更新 pkg-config。

对于库来说，如果它支持使用 pkg-config，则可以使用 pkg-config
来查看其版本号。例如，对于 GTK+ 2.0 库来说，可以这样：

$ pkg-config --modversion gtk+-2.0

注：不妨执行上面的命令看看 GTK+
库是否已经在系统存在了；如果已经存在，注意它的版本号。还可以执行下面的命令查看使用
GTK+ 库时的编译和连接选项：

$ pkg-config --cflags --libs gtk+-2.0

通过显示出来的信息中的 -I 后面的路径可以大体知道 GTK+
及其依赖库的安装位置。看看它们是不是都位于 /usr 目录下。

4. 安装规划

4.1 系统上未安装 GTK+

通过上面的检查，如果发现系统上没有安装 GTK+，那问题就变得简单了：直接将
GTK+ 及其依赖库安装到 /usr 目录下即可（至于如何把各个库的安装目录设置为
/usr，可参看下面有关的安装说明）。这样做的好处是：由于 /usr
是系统目录，几乎不需要对安装的库进行什么设置就能够马上使用它们。

/usr
是一个重要的系统目录，应该尽量避免对这个目录进行写操作。因此，建议源码安装
GTK+ 不要将它安装在 /usr
等系统目录下；可另选择一其它目录（具体参见下面的相关说明）。

4.2 系统上已安装 GTK+

如果系统中已经安装有 GTK+，要安装新版本的 GTK+
时需要考虑的问题就多一些了。在 Linux 系统上使用的很多软件都是在 GTK+
库的支持下运行的（比如 GNOME 桌面）。如果相关的 GTK+
库发生损坏，或者库的版本发生了变化，轻微的可造成某些程序不能正常运行，严重的可能会给系统运行带来障碍（比如进入不了桌面环境，等等。）

因此，新版本的 GTK+ 的安装应该避免对原来的 GTK+
造成影响，以保证系统的正常运行。这一点很容易做到：新版 GTK+
的安装目录要避免和已经存在的 GTK+ 的目录一致。比如，如果旧版的 GTK+ 安装在
/usr 目录下，新版 GTK+ 在设置安装目录的时候最好就不要设置为 /usr 了。

一些人由于不了解这些情况，或者图方便，直接就把 GTK+ 安装在 /usr
中、从而把原来的 GTK+ 库给替换了。由于 GTK+
及其兼容库版本的变化以及可能在安装过程中产生的错误，很容易出现上面提到的问题，所以建议在安装新版
GTK+ 时，最好避开旧版 GTK+ 所在的目录。

GTK+
安装在什么目录中为好呢？其实，这没有什么定论，可自行设置安装的目录。不过，一般的源码软件包默认的安装目录是
/usr/local，所以可以把这个目录设置为 GTK+
的安装目录，也可以是其它你认为合适的目录。在下面的示例安装中，我们使用的安装目录是
/opt/gtk，GTK+ 及其依赖库都将安装在这个目录下。

将 GTK+ 及其依赖库设置安装到同一个目录下（如
/opt/gtk）、而不是每一个库占用一个不同的目录，可以给以后的库的设置带来方便。而且，在将来不再需要这个版本的
GTK+ 及其依赖库的时候可以通过删除这个目录（如 /opt/gtk）将它们简单地去除。

和安装到 /usr
目录中不同，如果将库安装到一个非系统目录中（比如我们将要使用的 /opt/gtk
目录），只将库安装完成还是不够的，还必须要进行一些必要的设置才能使用这个新安装好的库。在下面的相关章节中讲对库的设置作具体说明。

5. 软件下载

按照上面"依赖软件包"一节中提供的说明和地址分别下载
GLib、Atk、Cairo、Pango、Gtk+ 这五个库。

在各自的下载目录中，通常列出了各种版本的软件包，而且一般每个版本都有
.tar.gz 和 .tar.bz2
两种不同压缩格式。要注意根据各个软件包的版本号或者日期选择一个最新的版本下载，有的库的下载目录下面也用一个
LATEST-xxx 的文件名告诉目前的最新版本是多少。由于 .tar.bz2
压缩格式的文件较小，推荐下载这种软件包；如果没有，再下载 .tar.gz 格式的包。

下面是目前各个库的最新版本的软件包：

* glib-2.12.5.tar.bz2
* atk-1.9.1.tar.bz2
* cairo-1.2.0.tar.gz
* pango-1.14.8.tar.bz2
* gtk+-2.10.6.tar.bz2

可以新建一个目录，用于存放以上这些下载的软件包。

由于这些软件包都是使用 GNU Autotools
工具创建的，所以各个软件包的构建和安装界面是相同的，都是 ./configure &&
make && make install。因此，我们重点介绍 Glib 库的安装，对包括 GTK+
在内的其它库只作简单说明；在安装其它库的时候，可比照 Glib
库的安装过程进行。

6. 库的安装

6.1 安装顺序

根据依赖关系的要求，库的安装要按照这样的先后顺序进行：GLib、Atk、Cairo、Pango、Gtk+。

上述各个库在安装的时候，都会自动检查其依赖的库是否已经正确安装；如果依赖库没有安装，或者安装不成功，或者没有正确进行设置等都会导致安装终止，并显示出相应的错误提示。不过，只要按照上面的顺序安装各个库，并严格按照下面的步骤操作，一般很容易在不出现任何错误的情况下顺利地完成各个库的安装。

6.2 安装过程

源码安装软件包的过程可划分为以下几个步骤：

* 解包
* 配置
* 构建
* 安装
* 设置

下面以 Glib 的安装为例分别具体介绍库安装的各个过程。

6.2.1 解包

解包就是将软件包解压还原的过程。首先要进入软件包所在的目录，根据根据软件包的类型是
.tar.gz 还是 .tar.bz2，选择相应的解包命令。

.tar.bz2 格式软件包的解压还原：

$ tar xjvf glib-2.12.5.tar.bz2

如果软件包是 .tar.gz 格式的话，应该这样解压还原：

$ tar xzvf glib-2.12.5.tar.gz

上面的解包命令执行之后，会在当前工作目录下生成一个名为 glib-2.12.5
的目录，Glib 软件包的内容都存放在这个目录下。

其它软件包的解包过程与上面类似，只要把上面命令中的软件包名替换即可。各个软件包解包之后生成的目录名一般是将软件包名中的
.tar.bz2 或者 .tar.gz 去除之后的名称，其格式是：库名-版本号。

6.2.2 配置

配置（configure）的目的和结果是获得软件构建和安装所需要的
Makefile。为此，在配置过程中将对当前系统进行检测，获得程序构建和安装所需要的一些信息并最终记录在
Makefile
中。其中的一些内容也可以通过命令行参数进行指定，比如软件包的安装路径（如果不特意指定安装路径的话，将默认使用
/usr/local 作为安装路径。）

在前面已经规划好了：我们要将所有的软件包都安装在 /opt/gtk
目录下面，所以可以这样做：

首先进入要安装的软件包目录。例如，如果是 Glib，可以执行 cd glib-2.12.5
命令进入目录。

其次，执行下面的命令进行配置（以后安装的各个软件包的配置命令也是下面的形式）：

$ ./configure --prefix=/opt/gtk

其中，configure 是在软件包中包含的一个脚本文件（是由 GNU Autotools
工具产生的），./configure 是执行这个脚本文件，用 --prefix
指明软件包的安装目录。这样，在随后的安装过程中（make
install）会把相应的文件拷贝到它后面指定的目录下（/opt/gtk）。

注：可以用 ./configure --help
命令查看各个软件包中配置时提供的不同的参数选项和各个参数的意义。

注：一个库可以有两种存在形态：共享库（.so）和静态库（.a）。对于 GTK+
及其依赖库，在源码安装的时候其默认设置是只生成共享库；如果需要静态库，应该在配置各个软件包的时候分别加上
--enable-static 参数（参见 ./configure --help）。开发 GTK
程序时一般应使用其共享库，可不安装静态库。

由于 Glib
只依赖于一些最基本的系统库，所以在执行配置的过程中应该不会出现任何问题才是。然而，对于
GTK＋和其它依赖库，如果在配置过程中发现需要的程序或者库不存在，或者版本不符合要求，都会显示相应的错误提示后异常中止配置过程。如果配置不成功，则不能继续进行下面的程序构建过程。

对新手来说，他们通常不清楚什么样的配置结果是成功的，什么是失败的。下面提供两种简单的检查配置是否成功的方法：

* 配置过程中输出的信息，除了显示在屏幕上之外，还记录在一个名为
config.log 的文件中。检查这个文件中是否有 configure: exit 0
这样的一句话（一般位于文件的后面部分或者最后一行）。如果是，说明配置成功；如果不是（比如
configure: exit 1）说明配置过程中出现了错误，配置失败。
* 在 ./configure 命令执行完毕后立即执行 echo $?
命令，检查它的输出结果。如果输出是 0，说明配置成功；0
之外的数字说明配置失败。在 Linux
系统上，可以用这个方法检查一个命令或程序在其结束后返回给系统的值是多少。一般
0 代表成功，非 0 表示程序异常退出。

6.2.3 构建

从源代码生成程序的过程称为构建（Build）。这里所说的"程序"是一个广义的概念：既可以是其一般意义上的二进制可执行程序（Program），也可以是一个文本形式的可执行脚本（Script），还可以是库（Library）、头文件（Header）、数据（Data）等等。一个软件包中往往包含以上一种或者多种形式的程序构建，其中以二进制可执行程序和库最为常见。

对于用编译型语言（如 C 或者 C++）写的程序来说（GTK+ 和它的一些依赖库就是用
C 语言写成的），软件的构建过程主要是编译和连接的过程。在 Linux
系统上，构建是通过执行 make 命令实现的：

$ make

make 是根据 Makefile 的内容来决定如何构建程序的，而这个 Makefile
就是上面配置的产物。执行 make
命令之后，程序的编译过程就开始了。这是一个比较耗时的过程，特别是对于一些大型的软件包（如
GTK+ 及其依赖库）来说更是这样。

make 结束后，也可以执行 echo $? 命令检查 make
是否执行成功。一般只要配置通过了，make 应该不会出现什么问题才是。

make
的结果，对于程序来说，主要生成的是可执行程序文件；对于库来说，主要生成的是库文件。下面的安装过程将把需要的文件拷贝到在配置时指定的安装目录中去。

6.2.4 安装

构建成功的软件包的安装是通过带 install 参数的 make 进行的：

$ make install

需要在此说明的是：在 Linux 系统，除了 root
用户和具有相应权限的用户之外，一般用户只有在自己的用户目录下才有写权限；对于用户目录之外的其它目录和文件，一般只能读而不能写。我们在配置的时候将设置的安装目录是
/opt/gtk，对于一般用户来说是只读的。如果是这样的话，上面的 make install
虽然被执行，但是由于没有写的权限，不能向这个目录中拷贝文件，所以安装是不成功的。

一般需要如下面这样先切换到 root 用户，然后再进行安装：

$ su
# make install

上面的"#"符号表示处于 root 状态下的命令行提示符。

在执行完 make install 之后，也可以用 echo $? 检查是否执行安装成功。

如果此时查看 /opt/gtk 目录，你会发现这个目录下又有几个子目录，如
bin、include、lib、share。这是因为每个库（如
Glib）又根据使用目的不同将安装文件进行了划分：bin 是执行文件目录，include
是头文件目录，lib 是库文件目录，share
是库的公用目录，包括本地翻译文件、各种格式的说明文档和例子程序等。

安装完成后，应该立即退出 root 用户，返回到原来的用户状态：

# exit

root 用户权限应该仅在切实需要的时候才使用。很多初学者无论做什么都是以 root
进行，以为这样方便。其实对于新手而言这最是要不得，很容易由于误操作而损坏系统。即使只有你一个人使用一个
Linux 系统，也应该注册一个普通用户、平时以一个普通用户的身份使用系统。

6.2.5 设置

新手往往不清楚为什么要对库进行设置，要进行什么样的设置。为此，在下面介绍了一些有关库的设置的背景知识。如果已经了解了这部分内容，或者急于进行实际的设置操作，可直接转到最后一小节"GTK+
及其依赖库的设置"。

6.2.5.1 搜索路径

上面的安装已经把库的各类文件拷贝到指定的安装目录中了，这个库也就可以被其它程序或者库来使用了。库的使用主要包括两方面的内容：对库的头文件的使用以及对库文件（静态库或共享库）的使用。相应地，库的设置也就是如何对这两类文件进行定位的问题。对文件进行定位通常是用设置文件的搜索路径的方法来解决的。在使用的过程中按照搜索路径的先后顺序查找，第一个找到文件将被使用。

库的头文件在程序中被包含使用，而且仅仅用在程序编译阶段，所以头文件的默认搜索路径是由编译器提供的。处于默认搜索路径内的头文件不需要进行搜索路径的设置即可直接使用。虽然每个编译器提供的头文件的默认搜索路径不尽相同，但是都把
/usr/include
作为默认的搜索路径之一。使用处于默认搜索路径之外的头文件需要在编译的时候通过编译命令的
-I 参数指定其路径。这是对头文件进行定位的方式。

库文件在连接（静态库和共享库）和运行（仅限于使用共享库的程序）时被使用，其搜索路径是在系统中进行设置的。一般
Linux 系统把 /lib 和 /usr/lib
两个目录作为默认的库搜索路径，所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：

1. 在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
2. 在 /etc/ld.so.conf 文件中添加库的搜索路径。

需要注意的是：第二种搜索路径的设置方式对于程序连接时的库（包括共享库和静态库）的定位已经足够了，但是对于使用了共享库的程序的执行还是不够的。这是因为为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，所以是直接读取库列表文件
/etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache
是一个非文本的数据文件，不能直接编辑，它是根据 /etc/ld.so.conf
中设置的搜索路径由 /sbin/ldconfig
命令将这些搜索路径下的共享库文件集中在一起而生成的（ldconfig 命令要以 root
权限执行）。因此，为了保证程序执行时对库的定位，在 /etc/ld.so.conf
中进行了库搜索路径的设置之后，还必须要运行 /sbin/ldconfig 命令更新
/etc/ld.so.cache 文件之后才可以。

在程序连接时，对于库文件（静态库和共享库）的搜索路径，除了上面的设置方式之外，还可以通过
-L 参数显式指定。因为用 -L
设置的路径将被优先搜索，所以在连接的时候通常都会以这种方式直接指定要连接的库的路径。

有的使用了共享库的程序，在编译和连接时都很顺利，但是在运行时却发生了找不到共享库的问题，其原因就是库的搜索路径没有设置，或者设置不正确。

6.2.5.2 编译和连接界面

一般来说，如果库的头文件不在 /usr/include 目录中，那么在编译的时候需要用
-I
参数指定其路径。由于同一个库在不同系统上可能位于不同的目录下，用户安装库的时候也可以将库安装在不同的目录下，所以即使使用同一个库，由于库的路径的不同，造成了用
-I
参数指定的头文件的路径也可能不同，其结果就是造成了编译命令界面的不统一。如果使用
-L
参数，也会造成连接界面的不统一。编译和连接界面不统一会为库的使用带来麻烦。

为了解决编译和连接界面不统一的问题，人们找到了一些解决办法。其基本思想就是：事先把库的位置信息等保存起来，需要的时候再通过特定的工具将其中有用的信息提取出来供编译和连接使用。这样，就可以做到编译和连接界面的一致性。其中，目前最为常用的库信息提取工具就是下面介绍的
pkg-config。

6.2.5.3 pkg-config

pkg-config 是通过库提供的一个 .pc
文件获得库的各种必要信息的，包括版本信息、编译和连接需要的参数等。这些信息可以通过
pkg-config 提供的参数单独提取出来直接供编译器和连接器使用。

在默认情况下，每个支持 pkg-config 的库对应的 .pc
文件在安装后都位于安装目录中的 lib/pkgconfig
目录下。例如，我们在上面已经将 Glib 安装在 /opt/gtk 目录下了，那么这个
Glib 库对应的 .pc 文件是 /opt/gtk/lib/pkgconfig 目录下一个叫 glib-2.0.pc
的文件（不妨看看这个文件的内容来获得对 .pc 文件的一些感性认识。）

使用 pkg-config 的 --cflags 参数可以给出在编译时所需要的选项，而 --libs
参数可以给出连接时的选项。例如，假设一个 sample.c 的程序用到了 Glib
库，就可以这样编译：

$ gcc -c `pkg-config --cflags glib-2.0` sample.c

然后这样连接：

$ gcc sample.o -o sample `pkg-config --libs glib-2.0`

或者上面两步也可以合并为以下一步：

$ gcc sample.c -o sample `pkg-config --cflags --libs glib-2.0`

可以看到：由于使用了 pkg-config
工具来获得库的选项，所以不论库安装在什么目录下，都可以使用相同的编译和连接命令，带来了编译和连接界面的统一。

使用 pkg-config 工具提取库的编译和连接参数有两个基本的前提：

1. 库本身在安装的时候必须提供一个相应的 .pc
文件。不这样做的库说明不支持 pkg-config 工具的使用。
2. pkg-config 必须知道要到哪里去寻找此 .pc 文件。

GTK+ 及其依赖库支持使用 pkg-config 工具，所以剩下的问题就是如何告诉
pkg-config 到哪里去寻找库对应的 .pc 文件，这也是通过设置搜索路径来解决的。

6.2.5.4 GTK+ 及其依赖库的设置

6.2.5.4.1 以编译和连接为目的的设置

对于支持 pkg-config 工具的 GTK+
及其依赖库来说，库的头文件的搜索路径的设置变成了对 .pc
文件搜索路径的设置。.pc 文件的搜索路径是通过环境变量 PKG_CONFIG_PATH
来设置的，pkg-config 将按照设置路径的先后顺序进行搜索，直到找到指定的 .pc
文件为止。

Linux 中环境变量的设置方式和使用的 shell 有关。在这里是以 bash
为例进行说明的。如果你发现这里的环境变量的设置方法不能成功的话，应该检查你在当前的终端中使用的是什么
shell：

$ ps --no-headers --format comm $$

注：如果 ps 被定义为别名，可能需要执行 \ps --no-headers --format comm $$
才行。

然后根据这种 shell 的环境变量的设置方法进行设置。如果系统中存在有 bash
的话，也可以将 shell 切换为 bash：

$ bash

这样就可以按照下面介绍的方法设置环境变量了。

安装完 Glib 后，在 bash 中应该进行如下设置：

$ export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH

可以执行下面的命令检查是否 /opt/gtk/lib/pkgconfig 路径已经设置在
PKG_CONFIG_PATH 环境变量中：

$ echo $PKG_CONFIG_PATH

这样设置之后，使用 Glib 库的其它程序或库在编译的时候 pkg-config
就知道首先要到 /opt/gtk/lib/pkgconfig 这个目录中去寻找 glib-2.0.pc
了（GTK+ 和其它的依赖库的 .pc
文件也将拷贝到这里，也会首先到这里搜索它们对应的 .pc 文件）。之后，通过
pkg-config 就可以把其中库的编译和连接参数提取出来供程序在编译和连接时使用。

另外还需要注意的是：环境变量的设置只对当前的终端窗口有效。如果到了没有进行上述设置的终端窗口中，pkg-config
将找不到新安装的 glib-2.0.pc 文件、从而可能使后面进行的安装（如 Glib
之后的 Atk 的安装）无法进行。

6.2.5.4.2 以连接和执行为目的的设置

前面已经说明过了，库搜索路径的设置有两种方式：在环境变量 LD_LIBRARY_PATH
中设置以及在 /etc/ld.so.conf 文件中设置。

其中，第二种设置方式需要 root 权限，以改变 /etc/ld.so.conf 文件并执行
/sbin/ldconfig 命令。而且，当系统重新启动后，所有的基于 GTK2
的程序在运行时都将使用新安装的 GTK+ 库。不幸的是，由于 GTK+
版本的改变，这有时会给应用程序带来兼容性的问题，造成某些程序运行不正常。

为了避免出现上面的这些情况，在 GTK+
及其依赖库的安装过程中对于库的搜索路径的设置将采用第一种方式进行。这种设置方式不需要
root 权限，设置也简单：

$ export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH

可以用下面的命令查看 LD_LIBRAY_PATH 的设置内容：

$ echo $LD_LIBRARY_PATH

至此，库的两种设置就完成了。

由于我们将 GTK+ 及其依赖库设置安装在同一目录中，所以上面的对环境变量
PKG_CONFIG_PATH 和 LD_LIBRAY_PATH
的设置在一个终端窗口中只要进行一次就可以了，以后安装其它库的时候不需要再行设置。

经过以上设置之后，使用了 Glib 的程序（如下面要安装的 Atk）就能够根据在
PKG_CONFIG_PATH 和 LD_LIBRAY_PATH 中设置的搜索路径找到新安装的 Glib
库了。如果不进行上面的设置，或者设置有误，可能找到的是旧版的
Glib，也可能出现找不到 Glib 的错误。

现在，可以执行下面的命令检查 Glib 的版本号：

$ pkg-config --modversion glib-2.0

如果显示的版本号和你进行安装的软件包中的版本号一致，那么恭喜你!
你已经成功地完成了 Glib 库的安装和设置，可以继续进行其它库的安装了。

6.3 其它库的安装

在确认已经成功安装了 Glib 之后，可以顺次安装其它的库。

6.3.1 安装 Atk

参考"安装
Glib"一节中的操作进行。如果始终在同一个终端窗口中操作的话，最后的设置过程可不执行。检查
Atk 的版本号：

$ pkg-config --modversion atk

6.3.2 安装 Cairo

参考"安装
Glib"一节中的操作进行。如果始终在同一个终端窗口中操作的话，最后的设置过程可不执行。检查
Cairo 的版本号：

$ pkg-config --modversion cairo

6.3.3 安装 Pango

参考"安装
Glib"一节中的操作进行。如果始终在同一个终端窗口中操作的话，最后的设置过程可不执行。检查
Pango 的版本号：

$ pkg-config --modversion pango

注意：配置 Pango 成功的另外一个标志是：在 ./configure
最后显示出来的一行信息 backends: FreeType X Xft Cairo 中应该有 Cairo
字样的出现。如果没有，比如象 backends: FreeType X Xft 这样，说明 Pango
的配置不成功；Pango 配置不成功，说明其依赖库 Cairo 没有安装或者 Cairo
库的设置不正确。

6.3.4 安装 Gtk+

参考"安装
Glib"一节中的操作进行。如果始终在同一个终端窗口中操作的话，最后的设置过程可不执行。检查
GTK＋ 的版本号：

$ pkg-config --modversion gtk+-2.0

7. 库的使用

7.1 库使用之前的设置

在我们采用的安装方案中，由于是使用环境变量对 GTK+
及其依赖库进行的设置，所以当系统重新启动、或者新开一个终端窗口之后，如果想使用新安装的
GTK+ 库，需要如上面那样重新设置 PKG_CONFIG_PATH 和 LD_LIBRARY_PATH
环境变量。

这种使用 GTK+
的方法，在使用之前多了一个对库进行设置的过程。虽然显得稍微繁琐了一些，但却是一种最安全的使用
GTK+ 库的方式，不会对系统上已经存在的使用了 GTK+ 库的程序（比如 GNOME
桌面）带来任何冲击。

为了使库的设置变得简单一些，可以把下面的这两句设置保存到一个文件中（比如
set_gtk-2.10 文件）:

export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH

之后，就可以用下面的方法进行库的设置了（其中的 source 命令也可以用 .
代替）：

$ source set_gtk-2.10

只有在用新版的 GTK+ 库开发应用程序、或者运行使用了新版 GTK+
库的程序的时候，才有必要进行上述设置。

如果想避免使用 GTK+
库之前上述设置的麻烦，可以把上面两个环境变量的设置在系统的配置文件中（如
/etc/profile）或者自己的用户配置文件中（如 ~/.bash_profile）
；库的搜索路径也可以设置在 /etc/ld.so.conf
文件中，等等。这种设置在系统启动时会生效，从而会导致使用 GTK+
的程序使用新版的 GTK+
运行库，这有可能会带来一些问题。当然，如果你发现用新版的 GTK+
代替旧版没有什么问题的话，使用这种设置方式是比较方便的。

7.2 库文档

使用一个库免不了要参考库的文档。GTK+
及其依赖库的各个库的参看文档也被安装，具体位置在安装目录的
share/gtk-doc/html 目录下分别存放。可以用浏览器分别打开每个目录中的
index.html，然后将其添加到网络书签中以便随时参考。