GCC 编译详解 （转）

GNU CC（简称为Gcc）是GNU项目中符合ANSI C标准的编译系统，能够编译用C、C++和Object C等语言编写的程序。Gcc不仅功能强大，而且可以编译如C、C++、Object C、Java、Fortran、Pascal、Modula-3和Ada等多种语言，而且Gcc又是一个交叉平台编译器，它能够在当前CPU平台上为多种不同体系结构的硬件平台开发软件，因此尤其适合在嵌入式领域的开发编译。本章中的示例，除非特别注明，否则均采用Gcc版本为4.0.0。

GCC入门基础

表3.6 Gcc所支持后缀名解释

后 缀 名

所对应的语言

后 缀 名

所对应的语言

.c

C原始程序

.s/.S

汇编语言原始程序

.C/.cc/.cxx

C++原始程序

.h

预处理文件（头文件）

.m

Objective-C原始程序

.o

目标文件

.i

已经过预处理的C原始程序

.a/.so

编译后的库文件

.ii

已经过预处理的C++原始程序

如本章开头提到的，Gcc的编译流程分为了四个步骤，分别为：

· 预处理（Pre-Processing）

· 编译（Compiling）

· 汇编（Assembling）

· 链接（Linking）

下面就具体来查看一下Gcc是如何完成四个步骤的。

首先，有以下hello.c源代码

include

2 “hello.c” 2

int main()

{

printf(“Hello! This is our embedded world!n”);

return 0;

}

由此可见，Gcc确实进行了预处理，它把”stdio.h”的内容插入到hello.i文件中。

（2）编译阶段

接下来进行的是编译阶段，在这个阶段中，Gcc首先要检查代码的规范性、是否有语法错误等，以确定代码的实际要做的工作，在检查无误后，Gcc把代码翻译成汇编语言。用户可以使用”-S”选项来进行查看，该选项只进行编译而不进行汇编，生成汇编代码。

[root@localhost Gcc]# Gcc –S hello.i –o hello.s

以下列出了hello.s的内容，可见Gcc已经将其转化为汇编了，感兴趣的读者可以分析一下这一行简单的C语言小程序是如何用汇编代码实现的。

.file “hello.c”

.section .rodata

.align 4

.LC0:

.string”Hello! This is our embedded world!”

.text

.globl main

.type main, @function

main:

pushl �p

movl %esp, �p

subl $8, %esp

andl $-16, %esp

movl $0, �x

addl $15, �x

addl $15, �x

shrl $4, �x

sall $4, �x

subl �x, %esp

subl $12, %esp

pushl $.LC0

call puts

addl $16, %esp

movl $0, �x

leave

ret

.size main, .-main

.ident “GCC: (GNU) 4.0.0 20050519 (Red Hat 4.0.0-8)”

.section .note.GNU-stack,”“,@progbits

（3）汇编阶段

汇编阶段是把编译阶段生成的”.s”文件转成目标文件，读者在此可使用选项”-c”就可看到汇编代码已转化为”.o”的二进制目标代码了。如下所示：

[root@localhost Gcc]# Gcc –c hello.s –o hello.o

（4）链接阶段

在成功编译之后，就进入了链接阶段。在这里涉及到一个重要的概念：函数库。

读者可以重新查看这个小程序，在这个程序中并没有定义”printf”的函数实现，且在预编译中包含进的”stdio.h”中也只有该函数的声明，而没有定义函数的实现，那么，是在哪里实现”printf”函数的呢？最后的答案是：系统把这些函数实现都被做到名为libc.so.6的库文件中去了，在没有特别指定时，Gcc会到系统默认的搜索路径”/usr/lib”下进行查找，也就是链接到libc.so.6库函数中去，这样就能实现函数”printf”了，而这也就是链接的作用。

函数库一般分为静态库和动态库两种。静态库是指编译链接时，把库文件的代码全部加入到可执行文件中，因此生成的文件比较大，但在运行时也就不再需要库文件了。其后缀名一般为”.a”。动态库与之相反，在编译链接时并没有把库文件的代码加入到可执行文件中，而是在程序执行时由运行时链接文件加载库，这样可以节省系统的开销。动态库一般后缀名为”.so”，如前面所述的libc.so.6就是动态库。Gcc在编译时默认使用动态库。

完成了链接之后，Gcc就可以生成可执行文件，如下所示。

[root@localhost Gcc]# Gcc hello.o –o hello

运行该可执行文件，出现正确的结果如下。

[root@localhost Gcc]# ./hello

Hello! This is our embedded world!

Gcc编译选项分析

Gcc有超过100个的可用选项，主要包括总体选项、告警和出错选项、优化选项和体系结构相关选项。以下对每一类中最常用的选项进行讲解。

（1）总体选项

Gcc的总结选项如表3.7所示，很多在前面的示例中已经有所涉及。

表3.7 Gcc总体选项列表

后缀名

所对应的语言

-c

只是编译不链接，生成目标文件“.o”

-S

只是编译不汇编，生成汇编代码

-E

只进行预编译，不做其他处理

-g

在可执行程序中包含标准调试信息

-o file

把输出文件输出到file里

-v

打印出编译器内部编译各过程的命令行信息和编译器的版本

-I dir

在头文件的搜索路径列表中添加dir目录

-L dir

在库文件的搜索路径列表中添加dir目录

-static

链接静态库

-llibrary

连接名为library的库文件

对于“-c”、“-E”、“-o”、“-S”选项在前一小节中已经讲解了其使用方法，在此主要讲解另外两个非常常用的库依赖选项“-I dir”和“-L dir”。

· “-I dir”

正如上表中所述，“-I dir”选项可以在头文件的搜索路径列表中添加dir目录。由于Linux中头文件都默认放到了“/usr/include/”目录下，因此，当用户希望添加放置在其他位置的头文件时，就可以通过“-I dir”选项来指定，这样，Gcc就会到相应的位置查找对应的目录。

比如在“/root/workplace/Gcc”下有两个文件：

include

include

include

include

The simplest example

hello.o: hello.c hello.h

gcc –c hello.c –o hello.o

接着就可以使用make了。使用make的格式为：make target，这样make就会自动读入Makefile（也可以是首字母小写makefile）并执行对应target的command语句，并会找到相应的依赖文件。如下所示：

[root@localhost makefile]# make hello.o

gcc –c hello.c –o hello.o

[root@localhost makefile]# ls

hello.c hello.h hello.o Makefile

可以看到，Makefile执行了“hello.o”对应的命令语句，并生成了“hello.o”目标体。

注意

在Makefile中的每一个command前必须有“Tab”符，否则在运行make命令时会出错。

Makefile变量

上面示例的Makefile在实际中是几乎不存在的，因为它过于简单，仅包含两个文件和一个命令，在这种情况下完全不必要编写Makefile而只需在Shell中直接输入即可，在实际中使用的Makefile往往是包含很多的文件和命令的，这也是Makefile产生的原因。下面就可给出稍微复杂一些的Makefile进行讲解：

sunq:kang.o yul.o

Gcc kang.o bar.o -o myprog

kang.o : kang.c kang.h head.h

Gcc –Wall –O -g –c kang.c -o kang.o

yul.o : bar.c head.h

Gcc - Wall –O -g –c yul.c -o yul.o

在这个Makefile中有三个目标体（target），分别为sunq、kang.o和yul.o，其中第一个目标体的依赖文件就是后两个目标体。如果用户使用命令“make sunq”，则make管理器就是找到sunq目标体开始执行。

这时，make会自动检查相关文件的时间戳。首先，在检查“kang.o”、“yul.o”和“sunq”三个文件的时间戳之前，它会向下查找那些把“kang.o”或“yul.o”做为目标文件的时间戳。比如，“kang.o”的依赖文件为：“kang.c”、“kang.h”、“head.h”。如果这些文件中任何一个的时间戳比“kang.o”新，则命令“gcc –Wall –O -g –c kang.c -o kang.o”将会执行，从而更新文件“kang.o”。在更新完“kang.o”或“yul.o”之后，make会检查最初的“kang.o”、“yul.o”和“sunq”三个文件，只要文件“kang.o”或“yul.o”中的任比文件时间戳比“sunq”新，则第二行命令就会被执行。这样，make就完成了自动检查时间戳的工作，开始执行编译工作。这也就是Make工作的基本流程。

接下来，为了进一步简化编辑和维护Makefile，make允许在Makefile中创建和使用变量。变量是在Makefile中定义的名字，用来代替一个文本字符串，该文本字符串称为该变量的值。在具体要求下，这些值可以代替目标体、依赖文件、命令以及makefile文件中其它部分。在Makefile中的变量定义有两种方式：一种是递归展开方式，另一种是简单方式。

递归展开方式定义的变量是在引用在该变量时进行替换的，即如果该变量包含了对其他变量的应用，则在引用该变量时一次性将内嵌的变量全部展开，虽然这种类型的变量能够很好地完成用户的指令，但是它也有严重的缺点，如不能在变量后追加内容（因为语句：CFLAGS = $(CFLAGS) -O在变量扩展过程中可能导致无穷循环）。

为了避免上述问题，简单扩展型变量的值在定义处展开，并且只展开一次，因此它不包含任何对其它变量的引用，从而消除变量的嵌套引用。

递归展开方式的定义格式为：VAR=var

简单扩展方式的定义格式为：VAR：=var

Make中的变量使用均使用格式为：$(VAR)

注意

变量名是不包括“:”、“#”、“=”结尾空格的任何字符串。同时，变量名中包含字母、数字以及下划线以外的情况应尽量避免，因为它们可能在将来被赋予特别的含义。

变量名是大小写敏感的，例如变量名“foo”、“FOO”、和“Foo”代表不同的变量。

推荐在makefile内部使用小写字母作为变量名，预留大写字母作为控制隐含规则参数或用户重载命令选项参数的变量名。

下面给出了上例中用变量替换修改后的Makefile，这里用OBJS代替kang.o和yul.o，用CC代替Gcc，用CFLAGS代替“-Wall -O –g”。这样在以后修改时，就可以只修改变量定义，而不需要修改下面的定义实体，从而大大简化了Makefile维护的工作量。

经变量替换后的Makefile如下所示：

OBJS = kang.o yul.o

CC = Gcc

CFLAGS = -Wall -O -g

sunq : $(OBJS)

(CC)(OBJS) -o sunq

kang.o : kang.c kang.h

(CC)(CFLAGS) -c kang.c -o kang.o

yul.o : yul.c yul.h

(CC)(CFLAGS) -c yul.c -o yul.o

可以看到，此处变量是以递归展开方式定义的。

Makefile中的变量分为用户自定义变量、预定义变量、自动变量及环境变量。如上例中的OBJS就是用户自定义变量，自定义变量的值由用户自行设定，而预定义变量和自动变量为通常在Makefile都会出现的变量，其中部分有默认值，也就是常见的设定值，当然用户可以对其进行修改。

预定义变量包含了常见编译器、汇编器的名称及其编译选项。下表3.14列出了Makefile中常见预定义变量及其部分默认值。

表3.14 Makefile中常见预定义变量

命 令 格 式

含义

AR

库文件维护程序的名称，默认值为ar

AS

汇编程序的名称，默认值为as

CC

C编译器的名称，默认值为cc

CPP

C预编译器的名称，默认值为$(CC) –E

CXX

C++编译器的名称，默认值为g++

FC

FORTRAN编译器的名称，默认值为f77

RM

文件删除程序的名称，默认值为rm –f

ARFLAGS

库文件维护程序的选项，无默认值

ASFLAGS

汇编程序的选项，无默认值

CFLAGS

C编译器的选项，无默认值

CPPFLAGS

C预编译的选项，无默认值

CXXFLAGS

C++编译器的选项，无默认值

FFLAGS

FORTRAN编译器的选项，无默认值

可以看出，上例中的CC和CFLAGS是预定义变量，其中由于CC没有采用默认值，因此，需要把“CC=Gcc”明确列出来。

由于常见的Gcc编译语句中通常包含了目标文件和依赖文件，而这些文件在Makefile文件中目标体的一行已经有所体现，因此，为了进一步简化Makefile的编写，就引入了自动变量。自动变量通常可以代表编译语句中出现目标文件和依赖文件等，并且具有本地含义（即下一语句中出现的相同变量代表的是下一语句的目标文件和依赖文件）。下表3.15列出了Makefile中常见自动变量。

表3.15Makefile中常见自动变量

命令格式

含义

$*

不包含扩展名的目标文件名称

$+

所有的依赖文件，以空格分开，并以出现的先后为序，可能包含重复的依赖文件

$<

第一个依赖文件的名称

$?

所有时间戳比目标文件晚的依赖文件，并以空格分开

命令格式

含义

$@

目标文件的完整名称

$^

所有不重复的依赖文件，以空格分开

$%

如果目标是归档成员，则该变量表示目标的归档成员名称

自动变量的书写比较难记，但是在熟练了之后会非常的方便，请读者结合下例中的自动变量改写的Makefile进行记忆。

OBJS = kang.o yul.o

CC = Gcc

CFLAGS = -Wall -O -g

sunq : $(OBJS)

(CC)^ -o $@

kang.o : kang.c kang.h

(CC)(CFLAGS) -c <−o@

yul.o : yul.c yul.h

(CC)(CFLAGS) -c <−o@

另外，在Makefile中还可以使用环境变量。使用环境变量的方法相对比较简单，make在启动时会自动读取系统当前已经定义了的环境变量，并且会创建与之具有相同名称和数值的变量。但是，如果用户在Makefile中定义了相同名称的变量，那么用户自定义变量将会覆盖同名的环境变量。

Makefile规则

Makefile的规则是Make进行处理的依据，它包括了目标体、依赖文件及其之间的命令语句。一般的，Makefile中的一条语句就是一个规则。在上面的例子中，都显示地指出了Makefile中的规则关系，如“(CC)(CFLAGS) -c <−o@”，但为了简化Makefile的编写，make还定义了隐式规则和模式规则，下面就分别对其进行讲解。

1．隐式规则

隐含规则能够告诉make怎样使用传统的技术完成任务，这样，当用户使用它们时就不必详细指定编译的具体细节，而只需把目标文件列出即可。Make会自动搜索隐式规则目录来确定如何生成目标文件。如上例就可以写成：

OBJS = kang.o yul.o

CC = Gcc

CFLAGS = -Wall -O -g

sunq : $(OBJS)

(CC)^ -o $@

为什么可以省略后两句呢？因为Make的隐式规则指出：所有“.o”文件都可自动由“.c”文件使用命令“(CC)(CPPFLAGS) (CFLAGS)−cfile.c–ofile.o”生成。这样“kang.o”和“yul.o”就会分别调用“(CC) (CFLAGS)−ckang.c−okang.o”和“(CC) $(CFLAGS) -c yul.c -o yul.o”生成。

注意

在隐式规则只能查找到相同文件名的不同后缀名文件，如”kang.o”文件必须由”kang.c”文件生成。

下表3.16给出了常见的隐式规则目录：

表3.16 Makefile中常见隐式规则目录

对应语言后缀名

规则

C编译：.c变为.o

(CC)–c(CPPFLAGS) $(CFLAGS)

C++编译：.cc或.C变为.o

(CXX)−c(CPPFLAGS) $(CXXFLAGS)

Pascal编译：.p变为.o

(PC)−c(PFLAGS)

Fortran编译：.r变为-o

(FC)−c(FFLAGS)

2．模式规则

模式规则是用来定义相同处理规则的多个文件的。它不同于隐式规则，隐式规则仅仅能够用make默认的变量来进行操作，而模式规则还能引入用户自定义变量，为多个文件建立相同的规则，从而简化Makefile的编写。

模式规则的格式类似于普通规则，这个规则中的相关文件前必须用“%”标明。使用模式规则修改后的Makefile的编写如下：

OBJS = kang.o yul.o

CC = Gcc

CFLAGS = -Wall -O -g

sunq : $(OBJS)

(CC)^ -o $@

%.o : %.c

(CC)(CFLAGS) -c <−o@

Make使用

使用make管理器非常简单，只需在make命令的后面键入目标名即可建立指定的目标，如果直接运行make，则建立Makefile中的第一个目标。

此外make还有丰富的命令行选项，可以完成各种不同的功能。下表3.17列出了常用的make命令行选项。

表3.17 make的命令行选项

命令格式

含 义

-C dir

读入指定目录下的Makefile

-f file

读入当前目录下的file文件作为Makefile

命令格式

含 义

-i

忽略所有的命令执行错误

-I dir

指定被包含的Makefile所在目录

-n

只打印要执行的命令，但不执行这些命令

-p

显示make变量数据库和隐含规则

-s

在执行命令时不显示命令

-w

如果make在执行过程中改变目录，则打印当前目录名

使用autotools

在上一小节，读者已经了解到了make项目管理器的强大功能。的确，Makefile可以帮助make完成它的使命，但要承认的是，编写Makefile确实不是一件轻松的事，尤其对于一个较大的项目而言更是如此。那么，有没有一种轻松的手段生成Makefile而同时又能让用户享受make的优越性呢？本节要讲的autotools系列工具正是为此而设的，它只需用户输入简单的目标文件、依赖文件、文件目录等就可以轻松地生成Makefile了，这无疑是广大用户的所希望的。另外，这些工具还可以完成系统配置信息的收集，从而可以方便地处理各种移植性的问题。也正是基于此，现在Linux上的软件开发一般都用autotools来制作Makefile，读者在后面的讲述中就会了解到。

autotools使用流程

正如前面所言，autotools是系列工具，读者首先要确认系统是否装了以下工具（可以用which命令进行查看）。

· aclocal

· autoscan

· autoconf

· autoheader

· automake

使用autotools主要就是利用各个工具的脚本文件以生成最后的Makefile。其总体流程是这样的：

· 使用aclocal生成一个“aclocal.m4”文件，该文件主要处理本地的宏定义；

· 改写“configure.scan”文件，并将其重命名为“configure.in”，并使用autoconf文件生成configure文件。

接下来，笔者将通过一个简单的hello.c例子带领读者熟悉autotools生成makefile的过程，由于在这过程中有涉及到较多的脚本文件，为了更清楚地了解相互之间的关系，强烈建议读者实际动手操作以体会其整个过程。

1．autoscan

它会在给定目录及其子目录树中检查源文件，若没有给出目录，就在当前目录及其子目录树中进行检查。它会搜索源文件以寻找一般的移植性问题并创建一个文件“configure.scan”，该文件就是接下来autoconf要用到的“configure.in”原型。如下所示：

[root@localhost automake]# autoscan

autom4te: configure.ac: no such file or directory

autoscan: /usr/bin/autom4te failed with exit status: 1

[root@localhost automake]# ls

autoscan.log configure.scan hello.c

如上所示，autoscan首先会尝试去读入“configure.ac”（同configure.in的配置文件）文件，此时还没有创建该配置文件，于是它会自动生成一个“configure.in”的原型文件“configure.scan”。

2．autoconf

configure.in是autoconf的脚本配置文件，它的原型文件“configure.scan”如下所示：

-- Autoconf --

Process this file with autoconf to produce a configure script.

AC_PREREQ(2.59)

The next one is modified by sunq

AC_INIT(FULL-PACKAGE-NAME,VERSION,BUG-REPORT-ADDRESS)

AC_INIT(hello,1.0)

The next one is added by sunq

AM_INIT_AUTOMAKE(hello,1.0)

AC_CONFIG_SRCDIR([hello.c])

AC_CONFIG_HEADER([config.h])

Checks for programs.

AC_PROG_CC

Checks for libraries.

Checks for header files.

Checks for typedefs, structures, and compiler characteristics.

Checks for library functions.

AC_CONFIG_FILES([Makefile])

AC_OUTPUT

下面对这个脚本文件进行解释：

· 以“#”号开始的行为注释。

· AC_PREREQ宏声明本文件要求的autoconf版本，如本例使用的版本2.59。

· AC_INIT宏用来定义软件的名称和版本等信息，在本例中省略了BUG-REPORT-ADDRESS，一般为作者的e-mail。

· AM_INIT_AUTOMAKE是笔者另加的，它是automake所必备的宏，也同前面一样，PACKAGE是所要产生软件套件的名称，VERSION是版本编号。

· AC_CONFIG_SRCDIR宏用来侦测所指定的源码文件是否存在，来确定源码目录的有

效性。在此处为当前目录下的hello.c。

· AC_CONFIG_HEADER宏用于生成config.h文件，以便autoheader使用。

· AC_CONFIG_FILES宏用于生成相应的Makefile文件。

· 中间的注释间可以添加分别用户测试程序、测试函数库、测试头文件等宏定义。

接下来首先运行aclocal，生成一个“aclocal.m4”文件，该文件主要处理本地的宏定义。如下所示：

[root@localhost automake]# aclocal

再接着运行autoconf，生成“configure”可执行文件。如下所示：

[root@localhost automake]# autoconf

[root@localhost automake]# ls

aclocal.m4 autom4te.cache autoscan.log configure configure.in hello.c

3．autoheader

接着使用autoheader命令，它负责生成config.h.in文件。该工具通常会从“acconfig.h”文件中复制用户附加的符号定义，因此此处没有附加符号定义，所以不需要创建“acconfig.h”文件。如下所示：

[root@localhost automake]# autoheader

4．automake

这一步是创建Makefile很重要的一步，automake要用的脚本配置文件是Makefile.am，用户需要自己创建相应的文件。之后，automake工具转换成Makefile.in。在该例中，笔者创建的文件为Makefile.am如下所示：

AUTOMAKE_OPTIONS=foreign

bin_PROGRAMS= hello

hello_SOURCES= hello.c

下面对该脚本文件的对应项进行解释。

· 其中的AUTOMAKE_OPTIONS为设置automake的选项。由于GNU（在第1章中已经有所介绍）对自己发布的软件有严格的规范，比如必须附带许可证声明文件COPYING等，否则automake执行时会报错。automake提供了三种软件等级：foreign、gnu和gnits，让用户选择采用，默认等级为gnu。在本例使用foreign等级，它只检测必须的文件。

· bin_PROGRAMS定义要产生的执行文件名。如果要产生多个执行文件，每个文件名用空格隔开。

· hello_SOURCES定义“hello”这个执行程序所需要的原始文件。如果”hello”这个程序是由多个原始文件所产生的，则必须把它所用到的所有原始文件都列出来，并用空格隔开。例如：若目标体“hello”需要“hello.c”、“sunq.c”、“hello.h”三个依赖文件，则定义hello_SOURCES=hello.c sunq.c hello.h。要注意的是，如果要定义多个执行文件，则对每个执行程序都要定义相应的file_SOURCES。

接下来可以使用automake对其生成“configure.in”文件，在这里使用选项“—adding-missing”可以让automake自动添加有一些必需的脚本文件。如下所示：

[root@localhost automake]# automake –add-missing

configure.in: installing ‘./install-sh’

configure.in: installing ‘./missing’

Makefile.am: installing ‘depcomp’

[root@localhost automake]# ls

aclocal.m4 autoscan.log configure.in hello.c Makefile.am missing

autom4te.cache configure depcomp install-sh Makefile.in config.h.in

可以看到，在automake之后就可以生成configure.in文件。

5．运行configure

在这一步中，通过运行自动配置设置文件configure，把Makefile.in变成了最终的Makefile。如下所示：

[root@localhost automake]# ./configure

checking for a BSD-compatible install… /usr/bin/install -c

checking whether build enVironment is sane… yes

checking for gawk… gawk

checking whether make sets $(MAKE)… yes

checking for Gcc… Gcc

checking for C compiler default output file name… a.out

checking whether the C compiler works… yes

checking whether we are cross compiling… no

checking for suffix of executables…

checking for suffix of object files… o

checking whether we are using the GNU C compiler… yes

checking whether Gcc accepts -g… yes

checking for Gcc option to accept ANSI C… none needed

checking for style of include used by make… GNU

checking dependency style of Gcc… Gcc3

configure: creating ./config.status

config.status: creating Makefile

config.status: executing depfiles commands

可以看到，在运行configure时收集了系统的信息，用户可以在configure命令中对其进行方便地配置。在./configure的自定义参数有两种，一种是开关式（–enable-XXX或–disable-XXX），另一种是开放式，即后面要填入一串字符（–with-XXX=yyyy）参数。读者可以自行尝试其使用方法。另外，读者可以查看同一目录下的”config.log”文件，以方便调试之用。

到此为止，makefile就可以自动生成了。回忆整个步骤，用户不再需要定制不同的规则，而只需要输入简单的文件及目录名即可，这样就大大方便了用户的使用。下面的图3.9总结了上述过程：

图3.9 autotools生成Makefile流程图

使用autotools所生成的Makefile

autotools生成的Makefile除具有普通的编译功能外，还具有以下主要功能（感兴趣的读者可以查看这个简单的hello.c程序的makefile）：

1．make

键入make默认执行”make all”命令，即目标体为all，其执行情况如下所示：

[root@localhost automake]# make

if Gcc -DPACKAGE_NAME=”” -DPACKAGE_TARNAME=”” -DPACKAGE_VERSION=”” -DPACKAGE_STRING=”” -DPACKAGE_BUGREPORT=”” -DPACKAGE=”hello” -DVERSION=”1.0” -I. -I. -g -O2 -MT hello.o -MD -MP -MF “.deps/hello.Tpo” -c -o hello.o hello.c;

then mv -f “.deps/hello.Tpo” “.deps/hello.Po”; else rm -f “.deps/hello.Tpo”; exit 1; fi

Gcc -g -O2 -o hello hello.o

此时在本目录下就生成了可执行文件“hello”，运行“./hello”能出现正常结果，如下所示：

[root@localhost automake]# ./hello

Hello!Autoconf!

2．make install

此时，会把该程序安装到系统目录中去，如下所示：

[root@localhost automake]# make install

if Gcc -DPACKAGE_NAME=”” -DPACKAGE_TARNAME=”” -DPACKAGE_VERSION=”” -DPACKAGE_STRING=”” -DPACKAGE_BUGREPORT=”” -DPACKAGE=”hello” -DVERSION=”1.0” -I. -I. -g -O2 -MT hello.o -MD -MP -MF “.deps/hello.Tpo” -c -o hello.o hello.c;

then mv -f “.deps/hello.Tpo” “.deps/hello.Po”; else rm -f “.deps/hello.Tpo”; exit 1; fi

Gcc -g -O2 -o hello hello.o

make[1]: Entering directory ‘/root/workplace/automake’

test -z “/usr/local/bin” || mkdir -p – “/usr/local/bin”

/usr/bin/install -c ‘hello’ ‘/usr/local/bin/hello’

make[1]: Nothing to be done for ‘install-data-am’.

make[1]: LeaVing directory ‘/root/workplace/automake’

此时，若直接运行hello，也能出现正确结果，如下所示：

[root@localhost automake]# hello

Hello!Autoconf!

3．make clean

此时，make会清除之前所编译的可执行文件及目标文件（object file, *.o），如下所示：

[root@localhost automake]# make clean

test -z “hello” || rm -f hello

rm -f *.o

4．make dist

此时，make将程序和相关的文档打包为一个压缩文档以供发布，如下所示：

[root@localhost automake]# make dist

[root@localhost automake]# ls hello-1.0-tar.gz

hello-1.0-tar.gz

可见该命令生成了一个hello-1.0-tar.gz的压缩文件。

由上面的讲述读者不难看出，autotools确实是软件维护与发布的必备工具，也鉴于此，如今GUN的软件一般都是由automake来制作的。

想一想

对于automake制作的这类软件，应如何安装呢？

Vi使用练习

1．实验目的

通过指定指令的Vi操作练习，使读者能够熟练使用Vi中的常见操作，并且熟悉Vi的三种模式，如果读者能够熟练掌握实验内容中所要求的内容，则表明对Vi的操作已经很熟练了。

2．实验内容

（1）在“/root”目录下建一个名为“/Vi”的目录。

（2）进入“/Vi”目录。

（3）将文件“/etc/inittab”复制到“/Vi”目录下。

（4）使用Vi打开“/Vi”目录下的inittab。

（5）设定行号，指出设定initdefault（类似于“id:5:initdefault”）的所在行号。

（6）将光标移到该行。

（7）复制该行内容。

（8）将光标移到最后一行行首。

（9）粘贴复制行的内容。

（10）撤销第9步的动作。

（11）将光标移动到最后一行的行尾。

（12）粘贴复制行的内容。

（13）光标移到“si::sysinit:/etc/rc.d/rc.sysinit”。

（14）删除该行。

（15）存盘但不退出。

（16）将光标移到首行。

（17）插入模式下输入“Hello,this is Vi world!”。

（18）返回命令行模式。

（19）向下查找字符串“0:wait”。

（20）再向上查找字符串“halt”。

（21）强制退出Vi，不存盘。

分别指出每个命令处于何种模式下？

3．实验步骤

（1）mkdir /root/Vi

（2）cd /root/Vi

（3）cp /etc/inittab ./

（4）Vi ./inittab

（5）:set nu（底行模式）

（6）17（命令行模式）

（7）yy

（8）G

（9）p

（10）u

（11）$

（12）p

（13）21G

（14）dd

（15）:w（底行模式）

（16）1G

（17）i 并输入“Hello,this is Vi world!”（插入模式）

（18）Esc

（19）/0:wait（命令行模式）

（20）?halt

（21）:q!（底行模式）

4．实验结果

该实验最后的结果只对“/root/inittab”增加了一行复制的内容：“id:5:initdefault”。

用Gdb调试有问题的程序

1．实验目的

通过调试一个有问题的程序，使读者进一步熟练使用Vi操作，而且熟练掌握Gcc编译命令及Gdb的调试命令，通过对有问题程序的跟踪调试，进一步提高发现问题和解决问题的能力。这是一个很小的程序，只有35行，希望读者认真调试。

2．实验内容

（1）使用Vi编辑器，将以下代码输入到名为greet.c的文件中。此代码的原意为输出倒序main函数中定义的字符串，但结果显示没有输出。代码如下所示：

include

hello.c

include “hello.h”

int main()

{

printf(“Hello everyone!n”);

}

hello.h

include

-- Autoconf --

Process this file with autoconf to produce a configure script.

AC_PREREQ(2.59)

AC_INIT(hello, 1.0)

AM_INIT_AUTOMAKE(hello,1.0)

AC_CONFIG_SRCDIR([hello.h])

AC_CONFIG_HEADER([config.h])

Checks for programs.

AC_PROG_CC

Checks for libraries.

Checks for header files.

Checks for typedefs, structures, and compiler characteristics.

Checks for library functions.

AC_OUTPUT(Makefile)

（5）保存退出，并重命名为configure.in。

（6）运行：aclocal。

（7）运行：autoconf，并用ls查看是否生成了configure可执行文件。

（8）运行：autoheader。

（9）用Vi编辑Makefile.am文件为：

AUTOMAKE_OPTIONS=foreign

bin_PROGRAMS=hello

hello_SOURCES=hello.c hello.h

（10）运行：automake。

（11）运行：./configure。

（12）运行：make。

（13）运行：./hello，查看结果是否正确。

（14）运行：make install。

（15）运行：hello，查看结果是否正确。

（16）运行：make dist。

（17）在当前目录下解压hello-1.0.tar.gz：tar –zxvf hello-1.0.tar.gz。

（18）进入解压目录：cd ./hello-1.0。

（19）下面开始Linux下常见的安装软件步骤：./configure。

（20）运行：make。

（21）运行：./hello（在正常安装时这一步可省略）。

（22）运行：make install。

（23）运行：hello，查看结果是否正确。

4．实验结果

能够正确使用autotools生成Makefile，并且能够安装成功短小的Hello软件。