轻轻松松产生 Makefile
许明彦 <myhsu@cyberdude.com
February 11, 1999
Abstract:
在 Unix 上写程式的人大概都碰过 Makefile，尤其是用 C 来开发程式的
人。用 make 来开发和编译程式的确很方便，可是要写出一个 Makefile
就不简单了。偏偏介绍 Makefile 的文件不多，GNU Make 那份印出来要几
百页的文件，光看完 Overview 就快阵亡了，难怪许多人闻 Unix 色变。
本文将介绍如何利用 GNU Autoconf 及 Automake 这两套软体来协助我们
『自动』产生 Makefile 档，并且让开发出来的软体可以像 Apache,
MySQL 和常见的 GNU 软体一样，只要会 “./configure”, “make”,
“make install” 就可以把程式安装到系统中。如果您有心开发 Open
Source 的软体，或只是想在 Unix 系统下写写程式。希望这份介绍文件能
帮助您轻松地进入 Unix Programming 的殿堂。
1. 简介
Makefile 基本上就是『目标』(target), 『关连』(dependencies) 和
『动作』三者所组成的一连串规则。而 make 就会根据 Makefile 的规则
来决定如何编译 (compile) 和连结 (link) 程式。实际上，make 可做的
不只是编译和连结程式，例如 FreeBSD 的 port collection 中，
Makefile 还可以做到自动下载原始程式套件，解压缩 (extract) ，修补
(patch)，设定，然後编译，安装至系统中。
Makefile 基本构造虽然简单，但是妥善运用这些规则就也可以变出许多不
同的花招。却也因此，许多刚开始学习写 Makefile 时会感到没有规范可
循，每个人写出来的 Makefile 长得都不太一样，不知道从何下手，而且
常常会受限於自己的开发环境，只要环境变数不同或路径改一下，可能
Makefile 就得跟着修改。虽然有 GNU Makefile Conventions (GNU
Makefile 惯例) 订出一些使用 GNU 程式设计时撰写 Makefile 的一些标
准和规范，但是内容很长而且很复杂, 并且经常做些调整，为了减轻程式
设计师维护 Makefile 的负担，因此有了 Automake。
程式设计师只需写一些预先定义好的巨集 (macro)，交给 Automake 处理
後会产生一个可供 Autoconf 使用的 Makefile.in 档。再配合利用
Autoconf 产生的自动设定档 configure 即可产生一份符合 GNU Makefile
惯例的 Makeifle 了。
2. 上路之前
在开始试着用 Automake 之前，请先确认你的系统已经安装以下的软体：
1. GNU Automake
2. GNU Autoconf
3. GNU m4
4. perl
5. GNU Libtool (如果你需要产生 shared library)
我会建议你最好也使用 GNU C/C++ 编译器 、GNU Make 以及其它 GNU 的
工具程式来做为开发的环境，这些工具都是属於 Open Source Software
不仅免费而且功能强大。如果你是使用 Red Hat Linux 可以找到所有上述
软体的 rpm 档，FreeBSD 也有现成的 package 可以直接安装，或着你也
可以自行下载这些软体的原始档回来 DIY。以下的范例是在 Red Hat
Linux 5.2 + CLE2 的环境下所完成的。

3. 一个简单的例子

Automake 所产生的 Makefile 除了可以做到程式的编译和连结，也已经把

如何产生程式文件 (如 manual page, info 档及 dvi 档) 的动作，还有

把原始程式包装起来以供散　的动作都考虑进去了，所以原始程式所存放

的目录架构最好符合 GNU 的标准惯例，接下来我拿 hello.c 来做为例

子。

在工作目录下建立一个新的子目录 “devel”，再在 devel 下建立一个

“hello” 的子目录，这个目录将作为我们存放 hello 这个程式及其相关

档案的地方：

% mkdir devel

% cd devel

% mkdir hello

% cd hello

用编辑器写个 hello.c 档，

#include <stdio.h>

int main(int argc, char** argv)

{

printf(“Hello, GNU!\n”);

return 0;

}

接下来就要用 Autoconf 及 Automake 来帮我们产生 Makefile 档了，

1. 用 autoscan 产生一个 configure.in 的雏型，执行 autoscan 後会产

生一个configure.scan 的档案，我们可以用它做为 configure.in

档的蓝本。

% autoscan

% ls

configure.scan hello.c

2. 编辑 configure.scan 档，如下所示，并且把它的档名改成

configure.in

dnl Process this file with autoconf to produce a con

figure script.

AC_INIT(hello.c)

AM_INIT_AUTOMAKE(hello, 1.0)

dnl Checks for programs.

AC_PROG_CC

dnl Checks for libraries.

dnl Checks for header files.

dnl Checks for typedefs, structures, and compiler ch

aracteristics.

dnl Checks for library functions.

AC_OUTPUT(Makefile)

3. 执行 aclocal 和 autoconf ，分别会产生 aclocal.m4 及 configure 两

个档案

% aclocal

% autoconf

% ls

aclocal.m4 configure configure.in hello.c

4. 编辑 Makefile.am 档，内容如下

AUTOMAKE_OPTIONS= foreign

bin_PROGRAMS= hello

hello_SOURCES= hello.c

5. 执行 automake –add-missing ，Automake 会根据 Makefile.am 档产生

一些档案，包含最重要的 Makefile.in

% automake –add-missing

automake: configure.in: installing `./install-sh’

automake: configure.in: installing `./mkinstalldirs’

automake: configure.in: installing `./missing’

6. 最後执行 ./configure ，

% ./configure

creating cache ./config.cache

checking for a BSD compatible install… /usr/bin/in

stall -c

checking whether build environment is sane… yes

checking whether make sets ${MAKE}… yes

checking for working aclocal… found

checking for working autoconf… found

checking for working automake… found

checking for working autoheader… found

checking for working makeinfo… found

checking for gcc… gcc

checking whether the C compiler (gcc ) works… yes

checking whether the C compiler (gcc ) is a cross-co mpiler… no

checking whether we are using GNU C… yes

checking whether gcc accepts -g… yes

updating cache ./config.cache

creating ./config.status

creating Makefile

现在你的目录下已经产生了一个 Makefile 档，下个 “make” 指令就可

以开始编译 hello.c 成执行档，执行 ./hello 和 GNU 打声招呼吧！

% make

gcc -DPACKAGE=\”hello\” -DVERSION=\”1.0\” -I. -I. -g -O2 -c he

llo.c

gcc -g -O2 -o hello hello.o

% ./hello

Hello! GNU!

你还可以试试 “make clean”，”make install”，”make dist” 看看

会有什麽结果。你也可以把产生出来的 Makefile 秀给你的老板，让他从

此对你刮目相看

4. 一探究竟

上述产生 Makefile 的过程和以往自行编写的方式非常不一样，舍弃传统

自行定义 make 的规则，使用 Automake 只需用到一些已经定义好的巨集

即可。我们把巨集及目标 (target) 写在 Makefile.am 档内，Automake

读入 Makefile.am 档後会把这一串已经定义好的巨集展开并且产生对应的

Makefile.in 档， 然後再由 configure 这个 shell script 根据

Makefile.in 产生适合的 Makefile。

[Figure 1:利用 autoconf 及 automake 产生 Makefile 的流程]

上图中表示在上一节范例中所要用的档案以及产生出来的档案，有星号

(*) 者代表可执行档。在此范例中可藉由 Autoconf 及 Automake 工具所

产生的档案有 configure.scan、aclocal.m4、configure、Makefile.in，

需要我们加入设定者为 configure.in 及 Makefile.am。

4.1 编辑 configure.in 档

Autoconf 是用来产生 ‘configure’ 档的工具。’configure’ 是一个

shell script，它可以自动设定原始程式以符合各种不同平台上 Unix 系

统的特性，并且根据系统叁数及环境产生合适的 Makefile 档或是C 的标

头档 (header file)，让原始程式可以很方便地在这些不同的平台上被编

译出来。Autoconf 会读取 configure.in 档然後产生 ‘configure’ 这个

shell script。

configure.in 档的内容是一连串 GNU m4 的巨集，这些巨集经过

autoconf 处理後会变成检查系统特徵的 shell script。configure.in 内

巨集的顺序并没有特别的规定，但是每一个 configure.in 档必须在所有

巨集前加入 AC_INIT 巨集，然後在所有巨集的最後面加上 AC_OUTPUT 巨

集。我们可先用 autoscan 扫描原始档以产生一个 configure.scan 档，

再对 configure.scan 做些修改成 configure.in 档。在范例中所用到的

巨集如下：

dnl

这个巨集後面的字不会被处理，可视为注解。

AC_INIT(FILE)

这个巨集用来检查原始码所在的路径，autoscan 会自动产生，我们

不必修改它。

AM_INIT_AUTOMAKE(PACKAGE,VERSION)

这是使用 Automake 所必备的巨集，PACKAGE 是我们所要产生软体套

件的名称，VERSION 是版本编号。

AC_PROG_CC

检查系统可用的 C 编译器，如果原始程式是用 C 写的就需要这个巨

集。

AC_OUTPUT(FILE)

设定 configure 所要产生的档案，如果是 Makefile 的话，

configure 便会把它检查出来的结果带入 Makefile.in 档然後产生

合适的 Makefile。

实际上，我们使用 Automake 时，还须要一些其它的巨集，这些额外的巨

集我们用 aclocal 来帮我们产生。执行 aclocal 会产生 aclocal.m4

档，如果没有特别的用途，我们可以不必修改它，用 aclocal 所产生的巨

集会告诉 Automake 怎麽做。

有了 configure.in 及 aclocal.m4 两个档案後，便可以执行 autoconf

来产生 configure 档了。

4.2 编辑 Makefile.am 档

接下来我们要编辑 Makefile.am 档，Automake 会根据 configure.in 中

的巨集把Makefile.am 转成 Makefile.in 档。Makefile.am 档定义我们所

要产的目标：

AUTOMAKE_OPTIONS

设定 automake 的选项。Automake 主要是帮助开发 GNU 软体的人员

维护软体套件，所以在执行 automake 时，会检查目录下是否存在标

准 GNU 软体套件中应具备的文件档案，例如 ‘NEWS’、’AUTHOR’、

‘ChangeLog’ 等文件档。设成 foreign 时，automake 会改用一般软

体套件的标准来检查。

bin_PROGRAMS

定义我们所要产生的执行档档名。如果要产生多个执行档，每个档名

用空白字元隔开。

hello_SOURCES

定义 ‘hello’ 这个执行档所需要的原始档。如果 ‘hello’ 这个程式

是由多个原始档所产生，必须把它所用到的原始档都列出来，以空白

字元隔开。假设 ‘hello’ 这个程式需要 ‘hello.c’、’main.c’、

‘hello.h’ 三个档案的话，则定义

hello_SOURCES= hello.c main.c hello.h

如果我们定义多个执行档，则对每个执行档都要定义相对的

filename_SOURCES。

编辑好 Makefile.am 档，就可以用 automake –add-missing 来产生

Makefile.in。加上 –add-missing 选项是告诉 automake 顺便帮我们加

入包装一个软体套件所必备的档案。Automake 产生出来的 Makefile.in

档是完全符合 GNU Makefile 的惯例，我们只要执行 configure 这个

shell script 便可以产生合适的 Makefile 档了。

4.3 使用 Makefile

利用 configure 所产生的 Makefile 档有几个预设的目标可供使用，我们

只拿其中几个简述如下：

make all
产生我们设定的目标，即此范例中的执行档。只打 make 也可以，此
时会开始编译原始码，然後连结，并且产生执行档。
make clean
清除之前所编译的执行档及目的档 (object file, *.o)。
make distclean
除了清除执行档和目的档外，也把 configure 所产生的 Makefile
也清除掉。
make install
将程式安装至系统中。如果原始码编译无误，且执行结果正确，便可
以把程式安装至系统预设的执行档存放路径。如果我们用
bin_PROGRAMS 巨集的话，程式会被安装至 /usr/local/bin 这个目录。
make dist
将程式和相关的档案包装成一个压缩档以供散播 (distribution) 。
执行完在目录下会产生一个以 PACKAGE-VERSION.tar.gz 为名称的档
案。PACKAGE 和 VERSION 这两个变数是根据 configure.in 档中
AM_INIT_AUTOMAKE(PACKAGE, VERSION) 的定义。在此范例中会产生
‘hello-1.0.tar.gz’ 的档案。
make distcheck
和 make dist 类似，但是加入检查包装後的压缩档是否正常。这个
目标除了把程式和相关档案包装成 tar.gz 档外，还会自动把这个压
缩档解开，执行 configure，并且进行 make all 的动作，确认编译
无误後，会显示这个 tar.gz 档已经准备好可供散播了。这个检查非
常有用，检查过关的套件，基本上可以给任何一个具备 GNU 发展环
境的人去重新编译。就 hello-1.tar.gz 这个范例而言，除了在 Red Hat Linux 上，在 FreeBSD 2.2.x 版也可以正确地重新编译。
要注意的是，利用 Autoconf 及 Automake 所产生出来的软体套件是可以
在没有安装 Autoconf 及 Automake 的环境上使用的，因为 configure 是
一个 shell script，它己被设计可以在一般 Unix 的 sh 这个 shell 下
执行。但是如果要修改 configure.in 及 Makefile.am 档再产生新的
configure 及 Makefile.in 档时就一定要有 Autoconf 及 Automake 了。
5. 相关讯息
Autoconf 和 Automake 功能十分强大，你可以从它们所附的 info 档找到
详细的用法。你也可以从许多现存的 GNU 软体或 Open Source 软体中找
到相关的 configure.in 或 Makefile.am 档，它们是学习 Autoconf 及
Automake 更多技巧的最佳范例。
这篇简介只用到了 Autoconf 及 Automake 的皮毛罢了，如果你有心加入
Open Source 软体开发的行列，希望这篇文件能帮助你对产生 Makefile
有个简单的依据。其它有关开发 GNU 程式或 C 程式设计及 Makefile 的
详细运用及技巧，我建议你从 GNU Coding Standards3 (GNU 编码标准规
定) 读起，里面包含了 GNU Makefile 惯例，还有发展 GNU 软体套件的标
准程序和惯例。这些 GNU 软体的线上说明文件可以在
http://www.gnu.org/ 这个网站上找到。
6. 结语
经由 Autoconf 及 Automake 的辅助，产生一个 Makefile 似乎不再像以
前那麽困难了，而使用 Autoconf 也使得我们在不同平台上或各家 Unix
之间散播及编译程式变得简单，这对於在 Unix 系统上开发程式的人员来
说减轻了许多负担。妥善运用这些 GNU 的工具软体，可以帮助我们更容易
去发展程式，而且更容易维护原始程式码。
About this document …
轻轻松松产生 Makefile1
This document was generated using the LaTeX2HTML translator
Version 98.2 beta6 (August 14th, 1998)
Copyright (C) 1993, 1994, 1995, 1996, Nikos Drakos, Computer
Based Learning Unit, University of Leeds.
Copyright (C) 1997, 1998, Ross Moore, Mathematics Department,
Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 -show_section_numbers automake.tex
The translation was initiated by on 1999-02-11
Footnotes
…\title1
本文件使用 ChiLaTeX 制作。
… Standards3
GNU Coding Standards, Richard Stallman.
1999-02-11

GCC使用手册

作者：Clock
 
1.前言

    GCC编译器的手册(GCC MANUAL)的英文版已经非常全面，并且结构也非常完善了，只是一直都没有中文的版本，我这次阅读了GCC编译器的主要内容，对手册的内容进行了结构性的了解，认为有必要对这次阅读的内容进行整理，为以后的工作做准备。

    由于我对这个英文手册的阅读也仅仅是结构性的。因此有很多地方并没有看，所以这篇文档的内容我也只能写出部分，对于以后需要详细了解的地方，会再往这篇文档中增添内容，需要增添的内容主要是编译器的各种开关。

2. GCC功能介绍

    GCC编译器完成从C、C++、objective-C等源文件向运行在特定CPU硬件上的目标代码的转换（这是任何一个编译器需要完成的任务）。

    GCC能够处理的源文件分为C、C++、Objective-C、汇编语言等。对于这些源文件，用他们的后缀名进行标示。GCC能够处理的后缀有：

a. *.c  *.C      (C语言)

b. *.cxx   *.cc  (C++语言)

c. *.m           (面向对象的C)

d. *.i           (预处理后的C语言源文件)

e. *.ii          (预处理后的C++语言源文件)

f. *.s *.S       (汇编语言)

h. *.h         (头文件)

目标文件可以是：

a. *.o     编译连接后的目标文件

b. *.a     库文件

编译器把编译生成目标代码的任务分为以下4步：

a.预处理，把预处理命令扫描处理完毕；

b.编译，把预处理后的结果编译成汇编或者目标模块；

c.汇编，把编译出来的结果汇编成具体CPU上的目标代码模块；

d.连接，把多个目标代码模块连接生成一个大的目标模块；

3.  GCC开关

    GCC的运行开关共分为11类，这是类开关从11个方面控制着GCC程序的运行，以达到特定的编译目的。

3.1.  全局开关(OVERALL OPTIONS)

    全局开关用来控制在“GCC功能介绍”中的GCC的4个步骤的运行，在缺省的情况下，这4个步骤都是要执行的，但是当给定一些全局开关后，这些步骤就会在某一步停止执行，这产生中间结果，例如可能你只是需要中间生成的预处理的结果或者是汇编文件(比如拟的目的是为了看某个CPU上的汇编语言怎么写)。

3.1.1.  –x  language

    对于源文件是用什么语言编写的，可以通过文件名的后缀来标示，也可以用这开关。指定输入文件是什么语言编写的，language 可以是如下的内容

a.  c

b. objective-c

c. c-header

d. c++

e.cpp-output

f.assembler

g.assembler-with-cpp

3.1.2.–x none

把上一节介绍的-x开关都给关掉了。

3.1.3.  –c

编译成把源文件目标代码，不做连接的动作。

3.1.4. –S

把源文件编译成汇编代码，不做汇编和连接的动作。

3.1.5. –E

只把源文件进行预处理之后的结果输出来。不做编译，汇编，连接的动作。

3.1.6.  –o file

指明输出文件名是file。

3.1.7. –v

把整个编译过程的输出信息都给打印出来。

3.1.8.–pipe

由于gcc的工作分为好几步才完成，所以需要在过程中生成临时文件，使用-pipe就是用管道替换临时文件。

3.2.  语言相关开关(Language Options)

用来处理和语言相关的控制开关。

3.2.1.–ansi

    这个开关让GCC编译器把所有的gnu的编译器特性都给关掉，让你的程序可以和ansi标准兼容。

    除了以上的开关外，语言相关开关还有很多，如果在以后的工作学习中遇到了再加不迟！3.3.预处理开关(Preprocessor Options)

用来控制预处理所设置的开关。

3.3.1. –include file

    在编译之前，把file包含进去，相当于在所有编译的源文件最前面加入了一个#include <file>语句，这样做更“省油”。

3.3.2. –imacros file

    同-include file 一样。不过这个文件在具体编译的时候只有里面定义的宏才起作用，所以值用来在file文件里面定义宏。

3.3.3. –nostdinc

    在搜寻include 的文件路径中去掉标准的c语言头文件搜索路径，例如stdio.h文件就是放在标准头文件搜索路径下。

3.3.4.  –nostdinc++

    同上，只是去掉的是标准C++语言的头文件搜索路径。

3.3.5. –C

    同-E参数配合使用。让预处理后的结果，把注释保留，让人能够比较好读它。

3.3.6. –Dmacro

    把macro定义为字符串’1’。

3.3.7. –Dmacro = defn

    把macro定义为defn。

3.3.8.  –Umacro

    把对macro的定义取消。

    除了以上的开关外，预处理相关开关还有很多，如果在以后的工作学习中遇到了再加不迟！

3.4.   汇编开关(Assembler Option)

    用来控制汇编行为的开关。

3.4.1.  –Wa , option

    把option作为开关送给汇编程序。如果option里面有逗号，则作为好几行进行处理。

3.5.连接开关(Linker Options)

    用来控制连接过程的开关选项。

3.5.1. object-file-name

3.5.2. –llibrary

    连接库文件开关。例如-lugl，则是把程序同libugl.a文件进行连接。

3.5.3. –lobjc

    这个开关用在面向对象的C语言文件的库文件处理中。

3.5.4.  –nostartfiles

    在连接的时候不把系统相关的启动代码连接进来。

3.5.5.   –nostdlib

    在连接的时候不把系统相关的启动文件和系统相关的库连接进来。

3.5.6. –static

    在一些系统上支持动态连接，这个开关则不允许动态连接。

3.5.7. –shared

    生成可共享的被其他程序连接的目标模块。

    连接相关的开关还有一些，以后需要的时候再补。

3.6.目录相关开关(Directory Options)

    用于定义与目录操作相关的开关。

3.6.1. –Idir

    宏include需要搜寻的目录。

3.6.2.–I-

    与-I开关类似。

3.6.3.–Ldir

    搜寻库文件(*.a)的路径。

    和目录相关的开关还有很多，以后需要再加。

3.7. 警告开关(Warning Options)

    与警告处理相关的开关。

3.7.1.–fsyntax-only

    只检查代码中的语法错误，但并没有输出。

3.7.2. –w

    禁止一切警告信息打印出来。

3.7.3. –Wno-import

    禁止对宏#import提出警告。

3.7.4. –pedantic

3.7.5.  –pedantic-errors

3.7.6.  –W

   还有很多与警告处理相关的开关，以后再补。

3.8. 调试开关(Debugging Options)

3.8.1.–g

    把调试开关打开，让编译的目标文件有调试信息。

    还有很多与调试处理相关的开关，以后再补。

3.9. 优化开关(Optimization Options)

    -O1 –O2 –O3 –O0，这些开关分别控制优化的强度，-O3最强。

3.10. 目标机开关(Target Options)

3.10.1. –b machine

    在有的时候，Gcc编译器编译出来的目标代码并不是在运行这个编译动作的机器上运行而是另外一台机器，这种编译叫做交叉编译，用来运行最终目标代码的得机器叫做目标机，machine就是用来指明目标机的类型的。

3.10.2.  –V version

    用来告诉编译器使用它的多少版本的功能，version参数用来表示版本。

3.11.   CPU相关开关(Machine Dependent Options)

    比较多，也是在交叉编译的时候用得着。以后再说。

3.12. 生成代码开关(Code Generation Options)
 
********************************************************************************************

GCC　使用指南
使用语法：

　　gcc [ option | filename ]…
　　g++ [ option | filename ]…

　　其中 option 为 gcc 使用时的选项(后面会再详述)，
　　而 filename 为欲以 gcc 处理的文件

说明：

　　这 C 与 C++ 的 compiler 已将产生新程序的相关程序整合起来。产
生一个新的程序需要经过四个阶段：预处理、编译、汇编、连结，而这两
个编译器都能将输入的文件做不同阶段的处理。虽然原始程序的扩展名可
用来分辨编写原始程序码所用的语言，但不同的compiler，其预设的处理
程序却各不相同：

　　gcc　　预设经由预处理过(扩展名为.i)的文件为 C 语言，并於程式
　　　　　 连结阶段以 C 的连结方式处理。

　　g++　　预设经由预处理过(扩展名为.i)的文件为 C++ 语言，并於程
序连结阶段以 C++ 的连结方式处理。

　　原始程序码的扩展名指出所用编写程序所用的语言，以及相对应的处
理方法：

　　.c　　C 原始程序　　　　　　　　  ；   预处理、编译、汇编
　　.C　　C++ 原始程序　　　　　　　　；   预处理、编译、汇编
　　.cc   C++ 原始程序　　　　　　　　；   预处理、编译、汇编
　　.cxx  C++ 原始程序　　　　　　　　；   预处理、编译、汇编
　　.m　　Objective-C 原始程序　　　　；   预处理、编译、汇编
　　.i　　已经过预处理之 C 原始程序　 ；   编译、汇编
　　.ii   已经过预处理之 C++ 原始程序 ；   编译、汇编
　　.s　　组合语言原始程序　　　　　　；   汇编
　　.S　　组合语言原始程序　　　　　　；   预处理、汇编
　　.h　　预处理文件(标头文件)　　　　；   (不常出现在指令行)

　　其他扩展名的文件是由连结程序来处理，通常有：

　　.o　　Object file
　　.a　　Archive file

　　除非编译过程出现错误，否则 “连结” 一定是产生一个新程序的最
　　後阶段。然而你也可以以 -c、-s 或 -E 等选项，将整个过程自四
　　个阶段中的其中一个停止。在连结阶段，所有与原始码相对应的
　　.o 文件、程序库、和其他无法自文件名辨明属性的文件(包括不以 .o
　　为扩展名的 object file 以及扩展名为 .a 的 archive file)都会
　　交由连结程序来处理(在指令行将那些文件当作连结程序的参数传给
　　连结程序)。

选项：

　　不同的选项必须分开来下：例如 `-dr’ 这个选项就与 `-d -r’ 大
　　不相同。

　　绝大部份的 `-f’ 及 `-W’ 选项都有正反两种形式：-fname 及
　　-fno-name (或 -Wname 及 -Wno-name)。以下只列出非预设的那个
　　形式。

　　以下是所有选项的摘要。以形式来分类。选项的意义将另辟小节说
　　明。

　　一般性(概略、常用的)选项
　　　　　　  -c -S -E -o file -pipe -v -x language

　　程序语言选项
　　　　　　  -ansi -fall-virtual -fcond-mismatch
　　　　　　  -fdollars-in-identifiers -fenum-int-equiv
　　　　　　  -fexternal-templates -fno-asm -fno-builtin
　　　　　　  -fno-strict-prototype -fsigned-bitfields
　　　　　　  -fsigned-char -fthis-is-variable
　　　　　　  -funsigned-bitfields -funsigned-char
　　　　　　  -fwritable-strings -traditional -traditional-cpp
　　　　　　  -trigraphs

　　编译时的警告选项
　　　　　　  -fsyntax-only -pedantic -pedantic-errors -w -W
　　　　　　  -Wall -Waggregate-return -Wcast-align -Wcast-qual
　　　　　　  -Wchar-subscript -Wcomment -Wconversion
　　　　　　  -Wenum-clash -Werror -Wformat -Wid-clash-len
　　　　　　  -Wimplicit -Winline -Wmissing-prototypes
　　　　　　  -Wmissing-declarations -Wnested-externs -Wno-import
　　　　　　  -Wparentheses -Wpointer-arith -Wredundant-decls
　　　　　　  -Wreturn-type -Wshadow -Wstrict-prototypes -Wswitch
　　　　　　  -Wtemplate-debugging -Wtraditional -Wtrigraphs
　　　　　　  -Wuninitialized -Wunused -Wwrite-strings

　　除错选项
　　　　　　  -a -dletters -fpretend-float -g -glevel -gcoff
　　　　　　  -gxcoff -gxcoff+ -gdwarf -gdwarf+ -gstabs -gstabs+
　　　　　　  -ggdb -p -pg -save-temps -print-file-name=library
　　　　　　  -print-libgcc-file-name -print-prog-name=program

　　最佳化选项
　　　　　　  -fcaller-saves -fcse-follow-jumps -fcse-skip-blocks
　　　　　　  -fdelayed-branch -felide-constructors
　　　　　　  -fexpensive-optimizations -ffast-math -ffloat-store
　　　　　　  -fforce-addr -fforce-mem -finline-functions
　　　　　　  -fkeep-inline-functions -fmemoize-lookups
　　　　　　  -fno-default-inline -fno-defer-pop
　　　　　　  -fno-function-cse -fno-inline -fno-peephole
　　　　　　  -fomit-frame-pointer -frerun-cse-after-loop
　　　　　　  -fschedule-insns -fschedule-insns2
　　　　　　  -fstrength-reduce -fthread-jumps -funroll-all-loops
　　　　　　  -funroll-loops -O -O2

　　预处理选项
　　　　　　  -Aassertion -C -dD -dM -dN -Dmacro[=defn] -E -H
　　　　　　  -idirafter dir -include file -imacros file -iprefix
　　　　　　  file -iwithprefix dir -M -MD -MM -MMD -nostdinc -P
　　　　　　  -Umacro -undef

　　汇编程序选项
　　　　　　  -Wa,option

　　连结程序选项
　　　　　　  -llibrary -nostartfiles -nostdlib -static -shared
　　　　　　  -symbolic -Xlinker option -Wl,option -u symbol

　　目录选项
　　　　　　  -Bprefix -Idir -I- -Ldir

　　Target Options
　　　　　　  -b  machine -V version

　　与机器(平台)相关的选项
　　　　　　  M680×0 Options
　　　　　　  -m68000 -m68020 -m68020-40 -m68030 -m68040 -m68881
　　　　　　  -mbitfield -mc68000 -mc68020 -mfpa -mnobitfield
　　　　　　  -mrtd -mshort -msoft-float

　　　　　　  VAX Options
　　　　　　  -mg -mgnu -munix

　　　　　　  SPARC Options
　　　　　　  -mepilogue -mfpu -mhard-float -mno-fpu
　　　　　　  -mno-epilogue -msoft-float -msparclite -mv8
　　　　　　  -msupersparc -mcypress

　　　　　　  Convex Options
　　　　　　  -margcount -mc1 -mc2 -mnoargcount

　　　　　　  AMD29K Options
　　　　　　  -m29000 -m29050 -mbw -mdw -mkernel-registers
　　　　　　  -mlarge -mnbw -mnodw -msmall -mstack-check
　　　　　　  -muser-registers

　　　　　　  M88K Options
　　　　　　  -m88000 -m88100 -m88110 -mbig-pic
　　　　　　  -mcheck-zero-division -mhandle-large-shift
　　　　　　  -midentify-revision -mno-check-zero-division
　　　　　　  -mno-ocs-debug-info -mno-ocs-frame-position
　　　　　　  -mno-optimize-arg-area -mno-serialize-volatile
　　　　　　  -mno-underscores -mocs-debug-info
　　　　　　  -mocs-frame-position -moptimize-arg-area
　　　　　　  -mserialize-volatile -mshort-data-num -msvr3 -msvr4
　　　　　　  -mtrap-large-shift -muse-div-instruction
　　　　　　  -mversion-03.00 -mwarn-passed-structs

　　　　　　  RS6000 Options
　　　　　　  -mfp-in-toc -mno-fop-in-toc

　　　　　　  RT Options
　　　　　　  -mcall-lib-mul -mfp-arg-in-fpregs -mfp-arg-in-gregs
　　　　　　  -mfull-fp-blocks -mhc-struct-return -min-line-mul
　　　　　　  -mminimum-fp-blocks -mnohc-struct-return

　　　　　　  MIPS Options
　　　　　　  -mcpu=cpu type -mips2 -mips3 -mint64 -mlong64
　　　　　　  -mlonglong128 -mmips-as -mgas -mrnames -mno-rnames
　　　　　　  -mgpopt -mno-gpopt -mstats -mno-stats -mmemcpy
　　　　　　  -mno-memcpy -mno-mips-tfile -mmips-tfile
　　　　　　  -msoft-float -mhard-float -mabicalls -mno-abicalls
　　　　　　  -mhalf-pic -mno-half-pic -G num -nocpp

　　　　　　  i386 Options
　　　　　　  -m486 -mno-486 -msoft-float -mno-fp-ret-in-387

　　　　　　  HPPA Options
　　　　　　  -mpa-risc-1-0 -mpa-risc-1-1 -mkernel -mshared-libs
　　　　　　  -mno-shared-libs -mlong-calls -mdisable-fpregs
　　　　　　  -mdisable-indexing -mtrailing-colon

　　　　　　  i960 Options
　　　　　　  -mcpu-type -mnumerics -msoft-float
　　　　　　  -mleaf-procedures -mno-leaf-procedures -mtail-call
　　　　　　  -mno-tail-call -mcomplex-addr -mno-complex-addr
　　　　　　  -mcode-align -mno-code-align -mic-compat
　　　　　　  -mic2.0-compat -mic3.0-compat -masm-compat
　　　　　　  -mintel-asm -mstrict-align -mno-strict-align
　　　　　　  -mold-align -mno-old-align

　　　　　　  DEC Alpha Options
　　　　　　  -mfp-regs -mno-fp-regs -mno-soft-float -msoft-float

　　　　　　  System V Options
　　　　　　  -G -Qy -Qn -YP,paths -Ym,dir

　　Code Generation Options
　　　　　　  -fcall-saved-reg -fcall-used-reg -ffixed-reg
　　　　　　  -finhibit-size-directive -fnonnull-objects
　　　　　　  -fno-common -fno-ident -fno-gnu-linker
　　　　　　  -fpcc-struct-return -fpic -fPIC
　　　　　　  -freg-struct-returno -fshared-data -fshort-enums
　　　　　　  -fshort-double -fvolatile -fvolatile-global
　　　　　　  -fverbose-asm

PRAGMAS
　　Two  `#pragma’  directives  are  supported for GNU C++, to
　　permit using the same header file for two purposes:  as  a
　　definition  of  interfaces to a given object class, and as
　　the full definition of the contents of that object  class.

　　#pragma interface
　　　　　　  (C++  only.)   Use  this  directive in header files
　　　　　　  that define object classes, to save space  in  most
　　　　　　  of  the  object files that use those classes.  Nor-
　　　　　　  mally, local copies of certain information  (backup
　　　　　　  copies of inline member functions, debugging infor-
　　　　　　  mation, and the internal tables that implement vir-
　　　　　　  tual  functions)  must  be kept in each object file
　　　　　　  that includes class definitions.  You can use  this
　　　　　　  pragma  to  avoid  such duplication.  When a header
　　　　　　  file containing `#pragma interface’ is included  in
　　　　　　  a  compilation, this auxiliary information will not
　　　　　　  be generated (unless the main input source file it-
　　　　　　  self  uses `#pragma implementation’).  Instead, the
　　　　　　  object files will contain references to be resolved
　　　　　　  at link time.

　　#pragma implementation

　　#pragma implementation “objects.h”
　　　　　　  (C++  only.)  Use this pragma in a main input file,
　　　　　　  when you want  full  output  from  included  header
　　　　　　  files  to be generated (and made globally visible).
　　　　　　  The included  header  file,  in  turn,  should  use
　　　　　　  `#pragma  interface’.  Backup copies of inline mem-
　　　　　　  ber functions, debugging information, and  the  in-
　　　　　　  ternal  tables  used to implement virtual functions
　　　　　　  are all generated in implementation files.

　　　　　　  If you use `#pragma implementation’ with  no  argu-
　　　　　　  ment,  it  applies to an include file with the same
　　　　　　  basename as  your  source  file;  for  example,  in
　　　　　　  `allclass.cc’,  `#pragma  implementation’ by itself
　　　　　　  is   equivalent　　to　　`#pragma　　implementation
　　　　　　  “allclass.h”‘.  Use the string argument if you want
　　　　　　  a single implementation file to include  code  from
　　　　　　  multiple header files.

　　　　　　  There  is no way to split up the contents of a sin-
　　　　　　  gle header file into multiple implementation files.

文件说明
　　file.c　　　　　　 C source file
　　file.h　　　　　　 C header (preprocessor) file
　　file.i　　　　　　 经预处理过的 C source file
　　file.C　　　　　　 C++ source file
　　file.cc　　　　　　C++ source file
　　file.cxx　　　　C++ source file
　　file.m　　　　　　 Objective-C source file
　　file.s　　　　　　 assembly language file
　　file.o　　　　　　 object file
　　a.out　　　　　　  link edited output
　　TMPDIR/cc*　　　　 temporary files
　　LIBDIR/cpp　　　　 preprocessor
　　LIBDIR/cc1　　　　 compiler for C
　　LIBDIR/cc1plus　　 compiler for C++
　　LIBDIR/collect　　 linker front end needed on some machines
　　LIBDIR/libgcc.a　　GCC subroutine library
　　/lib/crt[01n].o　　start-up routine
　　LIBDIR/ccrt0　　additional start-up routine for C++
　　/lib/libc.a　　　　standard C library, 参阅 man page intro(3)
　　/usr/include　　standard directory for #include files
　　LIBDIR/include　　 standard gcc directory for #include files
　　LIBDIR/g++-include additional g++ directory for #include

　　LIBDIR is usually /usr/local/lib/machine/version.
　　TMPDIR comes from the environment variable TMPDIR (default
　　/usr/tmp if available, else /tmp).