kernel/kernel_Notes
1
0
Fork 0
mirror of https://github.com/beyondx/Notes.git synced 2026-02-03 18:33:26 +08:00
Code Issues Packages Projects Releases Wiki Activity

updated

Browse Source
This commit is contained in:
geekard
2012-12-30 17:47:01 +08:00
parent f8638a5844
commit d94d414d18
24 changed files with 472 additions and 4074 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
Zim/.zim/index.db
View File

Binary file not shown.

4
Zim/.zim/state.conf
View File

@@ -1,7 +1,7 @@
[History]
list=[["Utils:gdb:gdb debugging",292,null],["Utils:gdb:gdb debugging:gdb pointer",284,null],["Utils:gdb:gdb debugging:gdb demo",340,null],["Research:Error Notes:\u4e0b\u8f7d\u9519\u8bef:chosen node create failed",0,null],["Programme:goagent",43,null],["Linux:accounts",0,null],["Utils:autoconf---automake",0,null],["Utils:autoconf---automake:\u4ee3\u7801",0,null],["Utils:blkid",0,null],["Utils:autoconf---automake",0,null],["Utils:gcc&g++",0,null],["Utils:gcc&g++:C++\u7f16\u8bd1\u521d\u6b65",0,null],["Utils:gdb",0,null],["Utils:gcc&g++:Installing---GCC--Configuration",0,null],["Utils:make",0,null],["Utils:\u5de5\u5177\u94fe",0,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",0,null],["Utils:\u5de5\u5177\u94fe:gcc&g++",0,null],["Utils:\u5de5\u5177\u94fe:gcc&g++:C++\u7f16\u8bd1\u521d\u6b65",0,null],["Utils:\u5de5\u5177\u94fe:autotut-Using GNU autoconf-automake-autoheader",0,null],["Utils:\u5de5\u5177\u94fe:automake\u53d8\u91cf",0,null],["Utils:irssi",0,null],["Utils:make",0,null],["Utils:\u5de5\u5177\u94fe:make",0,null],["Utils:script",null,null]]
list=[["Utils:\u5de5\u5177\u94fe:autoconf---automake:Autoconf\u5b66\u4e60\u7b14\u8bb0",7575,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b",849,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",3328,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b",1475,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",3328,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b",3346,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",3328,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b",65,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:demo.c",40,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:foo.c",39,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:demo.c",1314,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:foo.c",135,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:demo.c",1314,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b",5599,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",3328,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b",10803,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:Autoconf\u5b66\u4e60\u7b14\u8bb0",7575,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:foo.c",135,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:autoreconf",2682,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:Autoconf\u5b66\u4e60\u7b14\u8bb0",7731,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:autoconf\u8f6f\u4ef6\u5305",698,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:Autoconf\u5b66\u4e60\u7b14\u8bb0",7731,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:autoconf\u8f6f\u4ef6\u5305",130,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:Autoconf\u5b66\u4e60\u7b14\u8bb0",873,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:Autotools\u4e0a\u624b\u6307\u5357",276,null]]
current=24
recent=[["Utils:gdb",0,null],["Utils:\u5de5\u5177\u94fe",0,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",0,null],["Utils:\u5de5\u5177\u94fe:gcc&g++",0,null],["Utils:\u5de5\u5177\u94fe:gcc&g++:C++\u7f16\u8bd1\u521d\u6b65",0,null],["Utils:\u5de5\u5177\u94fe:autotut-Using GNU autoconf-automake-autoheader",0,null],["Utils:\u5de5\u5177\u94fe:automake\u53d8\u91cf",0,null],["Utils:irssi",0,null],["Utils:\u5de5\u5177\u94fe:make",0,null],["Utils:script",null,null]]
recent=[["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u56fe\u89e3autoscan\u3001aclocal\u3001autoheader\u3001automake\u3001autoconf\u3001configure\u3001make",0,null],["Utils:\u5de5\u5177\u94fe:automake\u53d8\u91cf",0,null],["Utils:\u5de5\u5177\u94fe:autotut-Using GNU autoconf-automake-autoheader",0,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:demo.c",1314,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",3328,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b",10803,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:foo.c",135,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:\u5b9e\u4f8b:autoreconf",2682,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:Autoconf\u5b66\u4e60\u7b14\u8bb0",873,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake:Autotools\u4e0a\u624b\u6307\u5357",276,null]]
[MainWindow]
windowsize=[1278,779]

129
Zim/.zim/state.conf.zim-new~
View File

@@ -1,129 +0,0 @@
[History]
list=[["Utils:gdb:gdb debugging:gdb demo",340,null],["Research:Error Notes:\u4e0b\u8f7d\u9519\u8bef:chosen node create failed",0,null],["Programme:goagent",43,null],["Linux:accounts",0,null],["Utils:autoconf---automake",0,null],["Utils:autoconf---automake:\u4ee3\u7801",0,null],["Utils:blkid",0,null],["Utils:autoconf---automake",0,null],["Utils:gcc&g++",0,null],["Utils:gcc&g++:C++\u7f16\u8bd1\u521d\u6b65",0,null],["Utils:gdb",0,null],["Utils:gcc&g++:Installing---GCC--Configuration",0,null],["Utils:make",0,null],["Utils:\u5de5\u5177\u94fe",0,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",0,null],["Utils:\u5de5\u5177\u94fe:gcc&g++",0,null],["Utils:\u5de5\u5177\u94fe:gcc&g++:C++\u7f16\u8bd1\u521d\u6b65",0,null],["Utils:\u5de5\u5177\u94fe:autotut-Using GNU autoconf-automake-autoheader",0,null],["Utils:\u5de5\u5177\u94fe:automake\u53d8\u91cf",0,null],["Utils:irssi",0,null],["Utils:make",0,null],["Utils:\u5de5\u5177\u94fe:make",0,null],["Utils:script",0,null],["Utils:\u5de5\u5177\u94fe",0,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",null,null]]
current=24
recent=[["Utils:gdb",0,null],["Utils:\u5de5\u5177\u94fe:gcc&g++",0,null],["Utils:\u5de5\u5177\u94fe:gcc&g++:C++\u7f16\u8bd1\u521d\u6b65",0,null],["Utils:\u5de5\u5177\u94fe:autotut-Using GNU autoconf-automake-autoheader",0,null],["Utils:\u5de5\u5177\u94fe:automake\u53d8\u91cf",0,null],["Utils:irssi",0,null],["Utils:\u5de5\u5177\u94fe:make",0,null],["Utils:script",0,null],["Utils:\u5de5\u5177\u94fe",0,null],["Utils:\u5de5\u5177\u94fe:autoconf---automake",null,null]]
[MainWindow]
windowsize=[1278,779]
show_sidepane=True
sidepane_pos=316
show_menubar=True
show_menubar_fullscreen=True
show_toolbar=True
show_toolbar_fullscreen=False
show_statusbar=True
show_statusbar_fullscreen=False
pathbar_type=recent
pathbar_type_fullscreen=none
readonly=False
windowpos=[0,19]
toolbar_style=None
toolbar_size=tiny
active_tabs=["Index",null,null,"Attachments"]
toggle_panes=["left_pane"]
left_pane=[true,276,"Index"]
right_pane=[false,200,null]
top_pane=[false,200,null]
bottom_pane=[false,200,null]
[ImportPageDialog]
windowsize=[500,400]
[NewPageDialog]
windowsize=[362,170]
[RenamePageDialog]
windowsize=[643,204]
[DeletePageDialog]
windowsize=[633,438]
[PropertiesDialog]
windowsize=[395,299]
[InsertDateDialog]
windowsize=[319,247]
lastusedformat=%A %d/%m/%Y
linkdate=True
calendar_expanded=False
[InsertImageDialog]
windowsize=[1280,749]
attach_inserted_images=False
last_image_folder=/home/geekard/Notes/Zim/Utils/gdb/gdb_debugging
[InsertLinkDialog]
windowsize=[328,156]
[EditImageDialog]
windowsize=[339,268]
[AttachFileDialog]
windowsize=[500,400]
last_attachment_folder=/home/geekard/Notes/Zim/Research/Error_Notes/\u7f16\u8bd1\u9519\u8bef/crdb
insert_attached_images=False
[PromptExistingFileDialog]
windowsize=[637,165]
[InsertTextFromFileDialog]
windowsize=[500,400]
[PreferencesDialog]
windowsize=[592,422]
[AttachmentBrowserPlugin]
active=True
bottompane_pos=516
[TaskListDialog]
windowsize=[550,400]
hpane_pos=75
[InsertSymbolDialog]
windowsize=[350,400]
[InsertScreenshotDialog]
windowsize=[212,148]
[WordCountDialog]
windowsize=[316,146]
[CustomToolManagerDialog]
windowsize=[410,299]
[OpenPageDialog]
windowsize=[298,118]
[NotebookDialog]
windowsize=[500,400]
[PageWindow]
windowsize=[500,400]
[CalendarDialog]
windowsize=[222,258]
[TagsPlugin]
treeview=tagged
tagcloud_sorting=score
[ExportDialog]
windowsize=[400,325]
document_root_url=
selection=page
selected_page=NonSQL:\u4e3a\u4ec0\u4e48\u8981\u7528\u975e\u5173\u7cfb\u6570\u636e\u5e93\uff1f
format=HTML
template=Default
template_file=None
document_root=absolute
output_folder=None
index_page=
output_file=/home/geekard/\u4e3a\u4ec0\u4e48\u8981\u7528\u975e\u5173\u7cfb\u6570\u636e\u5e93\uff1f.html
[MovePageDialog]
windowsize=[411,157]
[FindAndReplaceDialog]
windowsize=[332,298]

243
Zim/Utils/autoconf---automake.txt
View File

@@ -1,243 +0,0 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-12-22T17:07:57+08:00
====== autoconf---automake ======
Created Thursday 22 December 2011
http://www.ibm.com/developerworks/cn/linux/l-makefile/
===== 引子 =====
无论是在Linux还是在Unix环境中，make都是一个非常重要的编译命令。不管是自己进行项目开发还是安装应用软件，我们都经常要用到make或 make install。利用make工具，我们可以将**大型的开发项目分解成为多个更易于管理的模块**，对于一个包括几百个源文件的应用程序，使用make和 makefile工具就可以轻而易举的理顺各个**源文件之间纷繁复杂的相互关系**。
但是如果通过查阅make的帮助文档来**手工编写Makefile**,对任何程序员都是一场挑战。幸而有GNU 提供的Autoconf及Automake这两套工具使得编写makefile不再是一个难题。
本文将介绍如何利用 GNU Autoconf 及 Automake 这两套工具来协助我们**自动产生 Makefile文件**，并且让开发出来的软件可以像大多数源码包那样，只需"./configure", "make","make install" 就可以把程序安装到系统中。
===== 模拟需求 =====
假设源文件按如下目录存放，如图1所示，运用autoconf和automake生成makefile文件。
图 1文件目录结构
{{./1.jpg}}
假设src是我们源文件目录，include目录存放其他库的头文件，lib目录存放用到的库文件，然后开始按模块存放，每个模块都有一个对应的目录，**模块下再分子模块**，如apple、orange。每个子目录下又分core，include，shell三个目录，其中core和shell目录存放.c文件，include的存放.h文件，其他类似。
样例程序功能：基于多线程的数据读写保护（联系作者获取整个autoconf和automake生成的Makefile工程和源码，E-mail：normalnotebook@126.com）。
===== 工具简介 =====
所必须的软件：autoconf/automake/m4/perl/libtool（其中libtool非必须）。
autoconf是一个用于生成可以**自动地配置软件源码包，用以适应多种UNIX类系统的shell脚本工具**，其中autoconf需要用到 m4，便于生成脚本。automake是一个**从Makefile.am文件自动生成Makefile.in的工具**。为了生成Makefile.in，automake还需用到perl，由于automake创建的发布完全遵循GNU标准，所以在创建中不需要perl。libtool是一款方便生成各种程序库的工具。
目前automake支持**三种目录层次**：flat、shallow和deep。
1) flat指的是所有文件都位于同一个目录中。
就是所有源文件、头文件以及其他库文件都位于当前目录中，且**没有子目录**。Termutils就是这一类。
2) shallow指的是主要的源代码都储存在顶层目录，其他各个部分则储存在子目录中。
就是主要源文件在当前目录中，而其它一些**实现各部分功能**的源文件位于各自不同的目录。automake本身就是这一类。
3) deep指的是所**有源代码都被储存在子目录中；顶层目录主要包含配置信息**。
就是所有源文件及自己写的头文件位于当前目录的一个子目录中，而当前目录里没有任何源文件。 GNU cpio和GNU tar就是这一类。
flat类型是最简单的，deep类型是最复杂的。不难看出，我们的模拟需求正是基于第三类deep型，也就是说我们要做挑战性的事情：)。注：我们的测试程序是基于多线程的简单程序。
===== 生成 Makefile 的来龙去脉 =====
首先进入 project 目录，在该目录下运行一系列命令，创建和修改几个文件，就可以生成符合**该平台**的Makefile文件，操作过程如下：
1) 运行autoscan命令
2) 将configure.scan 文件重命名为configure.in，并修改configure.in文件
3) 在**project目录**下新建Makefile.am文件，并在**core和shell**目录下也新建makefile.am文件
4) 在project目录下新建NEWS、 README、 ChangeLog 、AUTHORS文件
5) 将/usr/share/automake-1.X/目录下的depcomp和complie文件拷贝到本目录下
6) 运行aclocal命令
7) 运行autoconf命令
8) 运行automake -a命令
9) 运行**./confiugre**脚本
可以通过图2看出产生Makefile的流程，如图所示：
图 2生成Makefile流程图
{{./2.gif}}
===== Configure.in的八股文(整个工程只需一个该文件) =====
当我们利用autoscan工具生成confiugre.scan文件时，我们需要将confiugre.scan重命名为confiugre.in文件。confiugre.in调用__一系列autoconf宏__来测试程序需要的或用到的__特性__是否存在以及这些特性的功能。
下面我们就来目睹一下confiugre.scan的庐山真面目：
# Process this file with autoconf to produce a **configure script**.
AC_PREREQ(2.59)
**AC_INIT**(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
AC_CONFIG_SRCDIR([config.h.in])
AC_CONFIG_HEADER([config.h])
# Checks for programs.
AC_PROG_CC
# Checks for libraries.
# FIXME: Replace `main' with a function in `-lpthread':
AC_CHECK_LIB([pthread], [main]) #main为在库pthread中检查的函数名。
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
**AC_OUTPUT**
#上述所有的[]中的内容需要自定义。
每个configure.scan文件都是以AC_INIT开头，以AC_OUTPUT结束。我们不难从文件中看出confiugre.in文件的一般布局：
AC_INIT
测试程序
测试函数库
测试头文件
测试类型定义
测试结构
测试编译器特性
测试库函数
测试系统调用
AC_OUTPUT
上面的调用次序只是**建议性质**的，但我们还是强烈建议不要随意改变对宏调用的__次序__。
现在就开始修改该文件：
$mv configure.scan configure.in
$vim configure.in
修改后的结果如下：
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
AC_PREREQ(2.59)
**AC_INIT**(test, 1.0, normalnotebook@126.com)
AC_CONFIG_**SRCDIR**([src/ModuleA/apple/core/test.c])
AM_CONFIG_HEADER(config.h)
**AM_INIT_AUTOMAKE**(test,1.0)
# Checks for programs.
AC_PROG_CC
# Checks for libraries.
# FIXME: Replace `main' with a function in `-lpthread':
AC_CHECK_LIB([pthread], [**pthread_rwlock_init**]) #库中的函数名称
AC_PROG___RANLIB__
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
**AC_OUTPUT**([Makefile #当前项目根目录
src/lib/Makefile
src/ModuleA/apple/core/Makefile
src/ModuleA/apple/shell/Makefile
])
其中要将AC_CONFIG_HEADER([config.h])修改为：AM_CONFIG_HEADER(**config.h**), 并加入AM_INIT_AUTOMAKE(test,1.0)。由于我们的测试程序是基于多线程的程序，所以要加入AC_PROG_RANLIB，不然运行automake命令时会出错。在AC_OUTPUT输入要创建的Makefile文件名。
由于我们在程序中使用了读写锁，所以需要对**库文件**进行检查，即AC_CHECK_LIB([pthread], [main])，该宏的含义如下：
{{./3.gif}}
其中，LIBS是link的一个选项，详细请参看后续的Makefile文件。由于我们在程序中使用了读写锁，所以我们测试**pthread库中是否存在pthread_rwlock_init函数**。
由于我们是基于deep类型来创建makefile文件，所以我们需要在**四处创建Makefile文件**。即：project目录下，lib目录下，core和shell目录下。
Autoconf提供了很多__内置宏来做相关的检测__，限于篇幅关系，我们在这里对其他宏不做详细的解释，具体请参看参考文献1和参考文献2，也可参看autoconf信息页。
===== 实战Makefile.am =====
Makefile.am是一种**比Makefile更高层次的规则**。只需指定要__生成什么__目标，它由__哪些源文件__生成，要__安装到__什么目录等构成。
表一列出了可执行文件、静态库、头文件和数据文件，四种书写Makefile.am文件个一般格式。
表 1Makefile.am一般格式
{{./4.gif}}
对于可执行文件和静态库类型，如果只想编译，不想安装到系统中，可以用**noinst_PROGRAMS**代替bin_PROGRAMS，**noinst_LIBRARIES**代替lib_LIBRARIES。
Makefile.am还提供了一些**全局变量**供所有的目标体使用：
表 2 Makefile.am中可用的全局变量
{{./5.gif}}
在Makefile.am中__尽量使用相对路径__，系统预定义了两个基本路径：
表 3Makefile.am中可用的路径变量
{{./6.gif}}
在上文中我们提到过安装路径，automake设置了默认的安装路径：
1) 标准安装路径
默认安装路径为：$(prefix) = /usr/local，可以通过./configure **--prefix**=<new_path>的方法来覆盖。
其它的预定义目录还包括：bindir = $(prefix)/bin, libdir = $(prefix)/lib, **datadir** = $(prefix)/share, **sysconfdir** = $(prefix)/etc等等。
2) 定义一个新的安装路径
比如test, 可定义testdir = $(prefix)/test, 然后test_DATA =test1 test2，则test1，test2会作为数据文件安装到$(prefix)/test目录下。
我们首先需要在工程顶层目录下（即project/）创建一个Makefile.am来指明包含的子目录：
__SUBDIRS__=src/lib src/ModuleA/apple/shell src/ModuleA/apple/core
**CURRENTPATH**=$(shell /bin/pwd)
**INCLUDES=**-I$(CURRENTPATH)/src/include -I$(CURRENTPATH)/src/ModuleA/apple/include
**export **INCLUDES
由于每个源文件都会用到相同的头文件，所以我们在最顶层的Makefile.am中包含了编译源文件时所用到的头文件，并导出，见蓝色部分代码。
我们将lib目录下的swap.c文件编译成libswap.a文件，被apple/shell/apple.c文件调用，那么lib目录下的Makefile.am如下所示：
**noinst**_LIBRARIES=__libswap.a__
libswap_a_SOURCES=swap.c
INCLUDES=-I**$(top_srcdir)**/src/includ
细心的读者可能就会问：怎么表1中给出的是bin_LIBRARIES，而这里是noinst_LIBRARIES？这是因为如果只想编译，而不想安装到系统中，就用noinst_LIBRARIES代替bin_LIBRARIES，对于可执行文件就用noinst_PROGRAMS代替bin_PROGRAMS。对于安装的情况，库将会安装到$(prefix)/lib目录下，可执行文件将会安装到${prefix}/bin。如果想安装该库，则Makefile.am示例如下：
bin_LIBRARIES=libswap.a
libswap_a_SOURCES=swap.c
INCLUDES=-I$(top_srcdir)/src/include
**swapincludedir=**$(includedir)/swap #自定义的一个变量
**swapinclude_HEADERS**=$(top_srcdir)/src/include/**swap.h**
最后两行的意思是将swap.h安装到${prefix}/include /swap目录下。
接下来，对于**可执行文件类型**的情况，我们将讨论如何写Makefile.am？对于编译apple/core目录下的文件，我们写成的Makefile.am如下所示：
noinst_PROGRAMS=test
test_SOURCES=test.c
test_**LDADD**=$(top_srcdir)/src/ModuleA/apple/shell/**apple.o** $(top_srcdir)/src/lib/libswap.a
test_**LDFLAGS**=-D_GNU_SOURCE
DEFS+=-D_GNU_SOURCE
#__LIBS__=-lpthread
由于我们的test.c文件在**链接时**，需要apple.o和libswap.a文件，所以我们需要在test_LDADD中包含这两个文件。对于Linux下的信号量/读写锁文件进行编译，需要在编译选项中指明-D_GNU_SOURCE。所以在test_LDFLAGS中指明。而test_LDFLAGS只是链接时的选项，**编译时同样需要指明该选项**，所以需要__DEFS来指明编译选项__，由于DEFS**已经有初始值**，所以这里用+=的形式指明。从这里可以看出，Makefile.am中的语法与Makefile的语法一致，也可以采用条件表达式。如果你的程序还包含其他的库，除了用AC_CHECK_LIB宏来指明外，还可以用LIBS来指明。
如果你只想编译某一个文件，那么Makefile.am如何写呢？这个文件也很简单，写法跟可执行文件的差不多，如下例所示：
noinst_PROGRAMS=apple
apple_SOURCES=apple.c
DEFS+=-D_GNU_SOURCE
我们这里只是欺骗automake，假装要生成apple文件，让它为我们**生成依赖关系和执行命令**。所以当你运行完automake命令后，然后修改apple/shell/下的**Makefile.in**文件，直接将LINK语句删除，即：
…….
clean-noinstPROGRAMS:
-test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS)
apple$(EXEEXT): $(apple_OBJECTS) $(apple_DEPENDENCIES)
@rm -f apple$(EXEEXT)
#$(LINK) $(apple_LDFLAGS) $(apple_OBJECTS) $(apple_LDADD) $(LIBS)
…….
通过上述处理，就可以达到我们的目的。从图1中不难看出为什么要修改Makefile.in的原因，而不是修改其他的文件。

BIN
Zim/Utils/autoconf---automake/1.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 6.5 KiB

BIN
Zim/Utils/autoconf---automake/2.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.8 KiB

BIN
Zim/Utils/autoconf---automake/3.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.8 KiB

BIN
Zim/Utils/autoconf---automake/4.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.6 KiB

BIN
Zim/Utils/autoconf---automake/5.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.6 KiB

BIN
Zim/Utils/autoconf---automake/6.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.4 KiB

38
Zim/Utils/autoconf---automake/代码.txt
View File

@@ -1,38 +0,0 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-12-22T22:26:12+08:00
====== 代码 ======
Created Thursday 22 December 2011
=== Autoconf ===
Autoconf (2.59):
ftp://ftp.gnu.org/gnu/autoconf/
===== Autoconf的内容 =====
Autoconf 能生成用于自动配置源代码的 shell 脚本(**configure**),该脚本可以生成makefile文件。
安装下列程序: autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate 和 ifnames
===== 简短说明 =====
autoconf是一个产生可以自动配置源代码包，生成shell脚本的工具，以适应各种类UNIX系统的需要。autoconf 产生的配置脚本在运行时独立于autoconf ，因此使用这些脚本的用户不需要安装autoconf。
autoheader能够产生供configure脚本使用的C #define语句模板文件。
autom4te对文件执行 GNU M4。
autoreconf，如果有多个autoconf产生的配置文件，autoreconf可以保存一些工作，它通过重复运行autoconf（以及在合适的地方运行autoheader）以重新产生autoconf配置脚本和配置头模板，这些文件保存在以当前目录为根的目录树中。
autoscan程序可以用来为软件包创建configure.in文件。autoscan在以命令行参数中指定的目录为根（如果未给定参数，则以当前目录为根）的目录树中检查源文件。它为通常的轻便问题搜索源文件，并且为那个包创建一个configure.scan文件，这个文件就是configure.in的前身。
autoupdate程序将一个调用autoconf 宏的旧名称的configure.in文件中的宏更新为新的名称。
ifnames当为一个软件包写configure.in 时，ifnames可以提供一些帮助。它打印包中那些在C预处理器中已经使用了的表示符。如果一个包已经设置成具有某些可移植属性，这个程序能够帮助指出它的配置应该如何检查。它可以用来填补由autoscan产生的configure.in中的隔阂。
Autoconf 安装依赖关系
Autoconf 依赖于: Bash, Coreutils, Diffutils, Grep, M4, Make, Perl, Sed.

7
Zim/Utils/gcc&g++.txt
View File

@@ -1,7 +0,0 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-11-11T17:37:05+08:00
====== gcc&g++ ======
Created Friday 11 November 2011

219
Zim/Utils/gcc&g++/C++编译初步.txt
View File

@@ -1,219 +0,0 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-11-11T17:37:12+08:00
====== C++编译初步 ======
Created Friday 11 November 2011
===== C++ 编程中相关文件后缀 =====
.a 静态库 (archive)
.C
.c
.cc
.cp
.cpp
.cxx
.c++ C++源代码（需要编译预处理）
.h C或者C++源代码头文件
.ii C++源代码（不需编译预处理）
.o 对象文件
.s 汇编语言代码
.so 动态库
<none> 标准C++系统头文件
===== 单个源文件生成可执行程序 =====
下面是一个保存在文件 helloworld.cpp 中一个简单的 C++ 程序的代码：
/* helloworld.cpp */
#include <iostream>
int main(int argc,char *argv[])
{
std::cout << "hello, world" << std::endl;
return(0);
}
程序使用定义在头文件 iostream 中的 cout，向标准输出写入一个简单的字符串。该代码可用以下命令编译为可执行文件：
$ g++ helloworld.cpp
编译器 g++ 通过检查命令行中指定的文件的后缀名可识别其为 C++ 源代码文件。编译器默认的动作：编译源代码文件生成对象文件(object file)，__链接__对象文件和 libstdc++ 库中的函数得到可执行程序。然后删除对象文件。由于命令行中未指定可执行程序的文件名，编译器采用默认的** a.out**。程序可以这样来运行：
$ ./a.out
hello, world
更普遍的做法是通过 -o 选项指定可执行程序的文件名。下面的命令将产生名为 helloworld 的可执行文件：
$ g++ helloworld.cpp -o helloworld
在命令行中输入程序名可使之运行：
$ ./helloworld
hello, world
程序 g++ 是将 gcc 默认语言设为 C++ 的一个特殊的版本，链接时它自动使用** C++ 标准库**而不用 C 标准库。通过遵循源码的命名规范并指定对应库的名字，用 gcc 来编译链接 C++ 程序是可行的，如下例所示：
$ gcc helloworld.cpp __-lstdc++__ -o helloworld
选项 -l (ell) 通过添加前缀 lib 和后缀 .a 将跟随它的名字变换为库的名字 libstdc++.a。而后它在标准库路径中查找该库。gcc 的编译过程和输出文件与 g++ 是完全相同的。
在大多数系统中，GCC 安装时会安装一名为 c++ 的程序。如果被安装，它和 g++ 是等同，如下例所示，用法也一致：
$ c++ helloworld.cpp -o helloworld
===== 多个源文件生成可执行程序 =====
如果多于一个的源码文件在 g++ 命令中指定，它们都将被编译并被链接成一个__单一__的可执行文件。下面是一个名为 speak.h 的头文件；它包含一个仅含有一个函数的类的定义：
/* speak.h */
#include <iostream>
class Speak
{
public:
void sayHello(const char *);
};
下面列出的是文件 speak.cpp 的内容：包含 sayHello() 函数的函数体：
/* speak.cpp */
#include "speak.h"
void Speak::sayHello(const char *str)
{
std::cout << "Hello " << str << "\n";
}
文件 hellospeak.cpp 内是一个使用 Speak 类的程序：
/* hellospeak.cpp */
#include "speak.h"
int main(int argc,char *argv[])
{
Speak speak;
speak.sayHello("world");
return(0);
}
下面这条命令将上述两个源码文件编译链接成一个单一的可执行程序：
$ g++ hellospeak.cpp speak.cpp -o hellospeak
PS：这里说一下为什么在命令中没有提到“speak.h“该文件（原因是：在“speak.cpp“中包含有”#include"speak.h"“这句代码，它的意思是搜索系统头文件目录之前将先在当前目录中搜索文件“speak.h“。而”speak.h“正在该目录中，不用再在命令中指定了）。
===== 源文件生成对象文件 =====
选项 -c 用来告诉编译器__编译__源代码但不要执行链接，输出结果为__对象文件__。文件默认名与源码文件名相同，只是将其后缀变为 .o。例如，下面的命令将编译源码文件 hellospeak.cpp 并生成对象文件 hellospeak.o：
$ g++ -c hellospeak.cpp
命令 g++ 也能识别 .o 文件并将其作为输入文件传递给链接器。下列命令将编译源码文件为对象文件并将其链接成单一的可执行程序：
$ g++ -c hellospeak.cpp
$ g++ -c speak.cpp
$ g++ hellospeak.o speak.o -o hellospeak
选项 -o 不仅仅能用来命名可执行文件。它也用来命名编译器输出的其他文件。例如：除了中间的对象文件有不同的名字外，下列命令生将生成和上面完全相同的可执行文件：
$ g++ -c hellospeak.cpp -o hspk1.o
$ g++ -c speak.cpp -o hspk2.o
$ g++ hspk1.o hspk2.o -o hellospeak
===== 编译预处理 =====
选项 __-E__ 使 g++ 将源代码用**编译预处理器**处理后不再执行其他动作。下面的命令预处理源码文件 helloworld.cpp 并将结果显示在__标准输出__中：
$ g++ -E helloworld.cpp
本文前面所列出的 helloworld.cpp 的源代码，仅仅有六行，而且该程序除了显示一行文字外什么都不做，但是，预处理后的版本将超过 **1200 **行。这主要是因为头文件 iostream 被包含进来，而且它又包含了其他的头文件，除此之外，还有若干个处理输入和输出的类的定义。
预处理过的文件的 GCC 后缀为__ .ii__，它可以通过 -o 选项来生成，例如：
$ gcc -E helloworld.cpp -o helloworld.ii
===== 生成汇编代码 =====
选项 __-S __指示编译器将程序编译成**汇编语言**，输出汇编语言代码而後结束。下面的命令将由 C++ 源码文件生成汇编语言文件 helloworld.s：
$ g++ -S helloworld.cpp
生成的汇编语言依赖于编译器的目标平台。
===== 创建静态库 =====
静态库是编译器生成的一系列**对象文件的集合**。链接一个程序时用库中的对象文件还是目录中的对象文件都是一样的。库中的成员包括普通函数，类定义，类的对象实例、全局变量、静态变量等等。静态库的另一个名字叫__归档文件__(archive)，管理这种归档文件的工具叫 ar 。
在下面的例子中，我们先创建两个对象模块，然后用其生成静态库。
头文件 say.h 包含函数 sayHello() 的原型和类 Say 的定义：
/* say.h */
#include <iostream>
void sayhello(void);
class Say {
private:
char *string;
public:
Say(char *str)
{
string = str;
}
void sayThis(const char *str)
{
std::cout << str << " from a static library\n";
}
void sayString(void);
};
下面是文件 say.cpp 是我们要加入到静态库中的两个对象文件之一的源码。它包含 Say 类中 sayString() 函数的定义体；类 Say 的一个**实例** librarysay 的声明也包含在内：
/* say.cpp */
#include "say.h"
void Say::sayString()
{
std::cout << string << "\n";
}
Say __librarysay__("Library instance of Say");
源码文件 sayhello.cpp 是我们要加入到静态库中的第二个对象文件的源码。它包含函数 sayhello() 的定义：
/* sayhello.cpp */
#include "say.h"
void sayhello()
{
std::cout << "hello from a static library\n";
}
下面的命令序列将源码文件编译成对象文件，命令 ar 将其存进库中：
$ g++ -c sayhello.cpp
$ g++ -c say.cpp
$ **ar -r libsay.a sayhello.o say.o**
程序 ar 配合参数 -r 创建一个新库 libsay.a 并将命令行中列出的对象文件插入。采用这种方法，如果库不存在的话，参数 -r 将创建一个新的库，而如果库存在的话，将用新的模块**替换**原来的模块。
下面是主程序 saymain.cpp，它调用库 libsay.a 中的代码：
/* saymain.cpp */
#include "say.h"
int main(int argc,char *argv[])
{
__ extern__ Say librarysay;
Say localsay = Say("Local instance of Say");
sayhello();
librarysay.sayThis("howdy");
librarysay.sayString();
localsay.sayString();
return(0);
}
该程序可以下面的命令来编译和链接：
$ g++ saymain.cpp **libsay.a** -o saymain
程序运行时，产生以下输出：
hello from a static library
howdy from a static library
Library instance of Say
Local instance of Say

220
Zim/Utils/gcc&g++/C编译初步.txt
View File

@@ -1,220 +0,0 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-11-11T18:00:47+08:00
====== C编译初步 ======
Created Friday 11 November 2011
http://wiki.ubuntu.org.cn/Compiling_C
===== C 编程中相关文件后缀 =====
.a 静态库 (archive)
.c C源代码（需要编译预处理）
.h C源代码头文件
__.i __ C源代码（不需编译预处理）
.o 对象文件
.s 汇编语言代码
.so 动态库
===== 单个源文件生成可执行程序 =====
下面是一个简单的“hello, ubuntu”程序的源代码：
/* helloubuntu.c */
#include <stdio.h>
int main(int argc,char *argv[])
{
printf("hello, ubuntu\n");
return 0;
}
最简单直接的编译该代码为可执行程序的方法是，将该代码保存为文件 helloubuntu.c，并执行以下命令：
$ gcc** -Wall **helloubuntu.c
编译器通过检查命令行中指定的文件的后缀名可识别其为 C 源代码文件。GCC 默认的动作：编译源代码文件生成对象文件(object file)，链接对象文件得到可执行程序，删除对象文件。由于命令行中未指定可执行程序的文件名，编译器采用默认的 a.out。在命令行中输入程序名可使其执行并显示结果：
$ ./a.out
hello, ubuntu
选项 -o 用来指定所生成的可执行程序的文件名。下面的命令生成名为 helloubuntu 的可执行程序：
$ gcc -Wall helloubuntu.c -o helloubuntu
在命令行中输入程序名将使其执行，如下：
$ ./helloubuntu
hello, ubuntu
注意如果有用到math.h库等非gcc默认调用的标准C库，请使用__ -lm__参数
===== 源文件生成对象文件 =====
选项 -c 指示 GCC 编译源代码文件，但将对象文件保留在磁盘中并跳过链接对象文件生成可执行文件这一步。在这种情况下，默认的输出文件的文件名同源代码文件名一致，只不过後缀换为 .o 。例如：下面的命令将生成名为 helloubuntu.o 的对象文件：
$ gcc -c -Wall helloubuntu.c
选项 -o 可用来指定生成的对象文件的文件名。以下命令将产生名为kubuntu.o的对象文件：
$ gcc -c -Wall helloubuntu.c -o kubuntu.o
当构建对象库或者生成一系列对象文件以备稍後链接用时，一条命令即可从多个源码文件生成对应的对象文件。下面的命令将__分别生成__对象文件ubuntu.o, kubuntu.o 与 xubuntu.o：
$ gcc -c -Wall ubuntu.c kubuntu.c xubuntu.c
===== 多个源文件生成可执行程序 =====
即使多个源码文件被编译，GCC编译器也会__自动进行链接__操作。例如：下面的代码保存在名为 hellomain.c 的文件中并调用一个名为 sayhello()的函数：
/* hellomain.c */
void sayhello(void);
int main(int argc,char *argv[])
{
sayhello();
return 0;
}
以下代码保存在名为 sayhello.c 的文件中并定义了 sayhello() 函数：
/* sayhello.c */
#include <stdio.h>
void sayhello()
{
printf("hello, ubuntu\n");/*这里有个小错误，是中文输入法造成的引号使gcc报错*/
}
下面的命令将两个文件分别编译为对象文件且将其链接为可执行程序 hello，并__自动删除__对象文件：
$ gcc -Wall hellomain.c sayhello.c -o hello
===== 编译预处理 =====
选项 **-E **指示编译器只进行编译预处理。下面的命令将预处理源码文件 helloubuntu.c 并将结果在**标准输出**中列出：
$ gcc -E helloubuntu.c
选项 -o 用来将预处理过的代码**重定向**到一个文件。像本文一开始给出的後缀列表所给出的，不需经过预处理的C源码文件保存为後缀为 __.i__的文件中，这种文件可以这样来获得：
$ gcc -E helloubuntu.c -o helloubuntu.i
===== 生成汇编代码 =====
选项 **-S **指示编译器生成汇编语言代码然後结束。下面的命令将由 C 源码文件 helloubuntu.c 生成汇编语言文件 helloubuntu.s：
$ gcc -S helloubuntu.c
汇编语言的形式依赖于编译器的目标平台。如果多个源码文件被编译，每个文件将分别产生对应的汇编代码模块。
===== 创建静态库 =====
静态库是编译器生成的普通的 .o 文件的集合。链接一个程序时用库中的对象文件还是目录中的对象文件都是一样的。静态库的另一个名字叫归档文件(archive)，管理这种归档文件的工具叫 ar 。
要构建一个库，首先要编译出库中需要的**对象模块**。例如，下面的两个源码文件为 hellofirst.c 和 hellosecond.c：
/* hellofirst.c */
#include <stdio.h>
void hellofirst()
{
printf(“The first hello\n”);
}
/* hellosecond.c */
#include <stdio.h>
void hellosecond()
{
printf(“The second hello\n”);
}
这两个源码文件可以用以下命令编译成对象文件：
$ gcc -c -Wall hellofirst.c hellosecond.c
程序 ar 配合参数 -r 可以创建一个新库并将对象文件插入。如果库不存在的话，参数 -r 将创建一个新的，并将对象模块添加（如有必要，通过替换）到归档文件中。下面的命令将创建一个包含本例中两个对象模块的名为 libhello.a 的静态库：
$ ar -r libhello.a hellofirst.o hellosecond.o
现在库已经构建完成可以使用了。下面的程序 twohellos.c 将调用该库中的这两个函数：
/* twohellos.c */
void hellofirst(void);
void hellosecond(void);
int main(int argc,char *argv[])
{
hellofirst();
hellosecond();
return 0;
}
程序 twohellos 可以通过在命令行中指定库用一条命令来编译和链接，命令如下：
$ gcc -Wall twohellos.c **libhello.a** -o twohellos
静态库的__命名惯例__是名字以三个字母 lib 开头并以後缀 .a 结束。所有的系统库都采用这种命名惯例，并且它允许通过__ -l(ell)__ 选项来简写命令行中的库名。下面的命令与先前命令的区别仅在于 gcc 期望的找寻该库的位置不同：
$ gcc -Wall twohellos.c -lhello -o twohellos
指定完整的路径名可使编译器在给定的目录中寻找库。库名可以指定为绝对路径（比如 /usr/worklibs/libhello.a）或者相对与当前目录的路径（比如 ./lib/libhello.a）。选项 -l 不能具有指定路径的能力，但是它要求编译器在__系统库目录__下找寻该库。
===== 创建共享库 =====
共享库是编译器以一种特殊的方式生成的对象文件的集合。对象文件模块中所有地址（变量引用或函数调用）都是__相对__而不是绝对的，这使得共享模块可以在程序的**运行过程中**被动态地调用和执行。
要构建一个共享库，首先要编译出库中需要的对象模块。例如：下面是文件名为 shellofirst.c 和 shellosecond.c 的两个源码文件：
/* shellofirst.c */
#include <stdio.h>
void shellofirst()
{
printf(“The first hello from a shared library\n”);
}
/* shellosecond.c */
#include <stdio.h>
void shellosecond()
{
printf(“The second hello from a shared library\n”);
}
要将以上两个源码文件编译成对象文件，可以用下面的命令：
$ gcc -c -Wall __-fpic __shellofirst.c shellosecond.c #这只是编译出共享库中的模块对象文件
选项 -c 告诉编译器只生成 .o 的对象文件。选项 -fpic 使生成的对象模块采用**浮动的（可重定位的）地址**。缩微词 pic 代表“__位置无关代码__”（position independent code）。
下面的 gcc 命令将对象文件构建成一个名为 hello.so 的共享库：
$ gcc -Wall __-shared__ shellofirst.o shellosecond.o -o hello.__so __
选项 -o 用来为输出文件命名，而文件後缀名 .so 告诉编译器将对象文件链接成一个共享库。通常情况下，链接器定位并使用 main() 函数作为程序的__入口__，但是本例中输出模块中没有这种入口点(同时也没有指定-c参数)，为抑制错误选项 -shared 是必须的。
编译器能将後缀为 .c 的文件识别为 C 语言源代码文件，并知道如何将其编译成为对象文件。基于这一点，先前的两条命令我们可以合并为一条;下面的命令直接将模块编译并存储为共享库：
$ gcc -Wall __-fpic -shared__ shellofirst.c shellosecond.c -o hello.so
下面的程序，存储在文件 stwohellos.c 内，是调用共享库中两个函数的主程序：
/* stwohellos.c */
void shellofirst(void);
void shellosecond(void);
int main(int argc,char *argv[])
{
shellofirst();
shellosecond();
return 0;
}
该程序可以用下面的命令编译并链接共享库：
$ gcc -Wall stwohellos.c **hello.so** -o stwohellos
程序 stwohello 已经完成，但要运行它必须让其能定位到共享库 hello.so，因为库中的函数要在程序运行时被加载。需要注意的是，当前工作目录可能不在__共享库的查找路径__中，因此需要使用如下的命令行设定环境变量__LD_LIBRARY_PATH__：
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./
===== 超越命名惯例 =====
如果环境要求你使用 .c 以外的後缀名来命名你的 C 源码文件，你可以通过 -x 选项来指定其对应的语言以忽略我们的命名规范。例如，下面的命令将从文件 helloworrld.jxj 编译 C 语言源代码并生成可执行文件 helloubuntu：
$ gcc -xc helloubuntu.jxj -o helloubuntu
通常，在没有 -x 选项的情况下，任何具有未知後缀名的源码文件名都被认为是__连接器可以识别__的选项，并在不做任何更改的情况下传递给链接器。选项 -x 对其後的所有未知後缀的文件都起作用。例如，下面的命令使 gcc 将 align.zzz 和 types.xxx 都作为 C 源码文件来处理：
$ gcc -c -xc align.zzz types.xxx

659
Zim/Utils/gcc&g++/Installing---GCC--Configuration.txt
View File

@@ -1,659 +0,0 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-12-20T10:35:59+08:00
====== Installing---GCC--Configuration ======
Created Tuesday 20 December 2011
http://gcc.gnu.org/install/configure.html
Like most GNU software, GCC must be **configured before it can be built**. This document describes the recommended configuration procedure for both native and cross targets.这里的native是原生目标，也就是说编译后生成的二进制文件运行的主机环境和编译的主机一样；cross是交叉编译目标，编译后生成的二进制文件的运行环境和编译主机不一样，如编译主机是i686-gun-linux环境，而目标文件的运行环境是powerpc-gun-linux。配置时，如果--build == --host则是native target， 否则是cross target。
We use** srcdir** to refer to the toplevel source directory for GCC; we use **objdir** to refer to the toplevel build/object directory.
If you obtained the sources via SVN, srcdir must refer to the top gcc directory, the one where the MAINTAINERS file can be found, and not its gcc subdirectory, otherwise the build will fail.
If either srcdir or objdir is located on an automounted NFS file system, the shell's built-in** pwd** command will return temporary pathnames. Using these can lead to various sorts of build problems. To avoid this issue, set the PWDCMD environment variable to an automounter-aware pwd command, e.g., pawd or `amq -w', during the configuration and build phases.
First, we highly recommend that GCC be __built into a separate directory__ from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a// subdirectory// of srcdir is unsupported.
If you have previously built GCC in the same directory for a **different target** machine, do `__make distclean__' to delete all files that might be invalid. One of the files this deletes is //Makefile//; if `make distclean' complains that Makefile does not exist or issues a message like “don't know how to make distclean” it probably means that the directory is already suitably clean. However, with the recommended method of building in a separate objdir, you should** simply use a different objdir** for each target.
Second, when configuring a native system, either **cc or gcc** must be in your path or you must set **CC** in your environment before running configure. Otherwise the configuration scripts may fail.
如果是cross target，则一定要指定环境变量CC为能产生--host主机环境二进制代码的compiler,例如在编译运行于powerpc-gun-linux上的glibc时，CC=/path/to/powerpc-gnu-linux-gcc。
To configure GCC:
% mkdir objdir
% cd objdir
% srcdir/configure [options] [target]
===== Distributor options =====
If you will be **distributing binary versions** of GCC, with modifications to the source code, you should use the options described in this section to make clear that your version contains modifications.
**--with-pkgversion=version**
Specify a string that identifies your package. You may wish to include a build number or build date. This version string will be included in the output of// gcc --version//. This** suffix** does not replace the default version string, only the `GCC' part.
The default value is `GCC'.
**--with-bugurl=url**
Specify the URL that users should visit if they wish to report a bug. You are of course welcome to forward bugs reported to you to the FSF, if you determine that they are not bugs in your modifications.
The default value refers to the FSF's GCC bug tracker.
===== Target specification =====
GCC has code to correctly determine the correct value for target for nearly all **native** systems. Therefore, we highly recommend you __do not provide a configure target when configuring a native compiler__.
target must be specified as **--target=target** when configuring a __cross compiler__; examples of valid targets would be m68k-elf, sh-elf, etc.
Specifying just target instead of --target=target implies that the host defaults to target.
===== Options specification =====
Use options to override several //configure time// options for GCC. A list of supported options follows; `configure --help' may list other options, but those not listed below may not work and should not normally be used.
Note that each --enable option has a corresponding --disable option and that each --with option has a corresponding --without option.
__--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**.
We highly recommend against dirname being the same or a subdirectory of objdir or vice versa. If specifying a directory beneath a user's home directory tree, some shells will not expand dirname correctly if it contains the `~' metacharacter; use $HOME instead.
The following standard **autoconf** options are supported. Normally you should **not need** to use these options.
--__exec-prefix__=dirname
Specify the__ toplevel installation directory__ for** architecture-dependent** files. The default is **prefix**.
--bindir=dirname
Specify the installation directory for the **executables** called by users (such as gcc and g++). The default is **exec-prefix/bin**.
--libdir=dirname
Specify the installation directory for **object code libraries and internal data files **of GCC. The default is **exec-prefix/lib**.
--libexecdir=dirname
Specify the installation directory for **internal executables** of GCC. The default is **exec-prefix/libexec**.
--with-slibdir=dirname
Specify the installation directory for the **shared libgcc library**. The default is libdir.
--__datarootdir__=dirname
Specify the root of the directory tree for** read-only architecture-independent data files** referenced by GCC. The default is **prefix/share**.
--infodir=dirname
Specify the installation directory for documentation in info format. The default is datarootdir/info.
--datadir=dirname
Specify the installation directory for **some architecture-independent data files** referenced by GCC. The default is datarootdir.
--docdir=dirname
Specify the installation directory for documentation files (other than Info) for GCC. The default is **datarootdir/doc**.
--htmldir=dirname
Specify the installation directory for HTML documentation files. The default is docdir.
--pdfdir=dirname
Specify the installation directory for PDF documentation files. The default is docdir.
--mandir=dirname
Specify the installation directory for manual pages. The default is datarootdir/man. (Note that the manual pages are only extracts from the full GCC manuals, which are provided in //Texinfo //format. The manpages are derived by an automatic conversion process from parts of the full manual.)
**--with-gxx-include-dir=dirname**
Specify the installation directory for** G++ header** files. The default depends on other configuration options, and differs between cross and native configurations.
**--with-specs=specs**
Specify additional command line driver SPECS. This can be useful if you need to turn on a non-standard feature by default without modifying the compiler's source code, for instance --with-specs=%{!fcommon:%{!fno-common:-fno-common}}. See “Spec Files” in the main manual
1.// toplevel installation directory : 程序文件的顶级安装目录，各个程序一般会在其下建立以//**程序名命名的单独目录。**
2.Installation directories:
--prefix=PREFIX install **architecture-independent** files in PREFIX [/usr/local]
--exec-prefix=EPREFIX install **architecture-dependent** files in EPREFIX [PREFIX]
--prefix指定程序被安装到的顶级目录，如果只有该选项而没有指定其它安装目录选项(如下所示)，一般编译后的程序的所有文件都会放在--prefix下的目录结构中。
3.Fine tuning of the installation directories:
--bindir=DIR **user **executables [EPREFIX/bin] #普通、管理员用户可执行的程序文件。
--sbindir=DIR **system admin** executables [EPREFIX/sbin] #管理员可执行的程序文件
--libdir=DIR object code libraries [EPREFIX/lib] #程序输出的库文件，库中存放的二进制对象文件可以供其它程序使用。
--libexecdir=DIR __program__ executables [EPREFIX/libexec] #供__程序(本程序或其它)调用__的可执行文件(用户一般__不会直接__调用它们)
以上四个选项控制与体系结构相关的二进制文件的存放位置，不同类型的二进制文件是用于不同目的的。
--sysconfdir=DIR ** read-only** single-machine data [__PREFIX/etc__]
--localstatedir=DIR **modifiable** single-machine data [PREFIX/var]
以上两个目录是程序执行时**读取配置文件，保存运行数据文件**的地方。
--includedir=DIR C header files [PREFIX/include]
~~ --oldincludedir=DIR C header files for non-gcc [/usr/include]~~
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
--datadir=DIR read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR info documentation [DATAROOTDIR/info]
--localedir=DIR locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR man documentation [DATAROOTDIR/man]
--docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE]
--htmldir=DIR html documentation [DOCDIR]
--dvidir=DIR dvi documentation [DOCDIR]
--pdfdir=DIR pdf documentation [DOCDIR]
--psdir=DIR ps documentation [DOCDIR]
以上选项是程序的体系结构无关的数据文件，程序不依赖它们运行。
一般情况下，以上所有选项的值都被__硬编码__到生成的可执行二进制文件中，所以程序在运行时可以到相关目录找到所需的文件。如果想增强程序的可移动性(位置无关性)，如将程序的安装目录移动到另一个位置后，程序还能够正常运行(如读取配置文件，存放临时数据)的话，相关选项需要使用__相对路径__。
**--program-prefix=prefix**
GCC supports some transformations of the names of its programs when installing them. This option prepends prefix to the names of programs to install in **bindir** (see above). For example, specifying //--program-prefix=//__foo-__ would result in `gcc' being installed as /usr/local/bin/foo-gcc.
**--program-suffix=suffix**
Appends suffix to the names of programs to install in bindir (see above). For example, specifying// --program-suffix=-3.1// would result in `gcc' being installed as [[/usr/local/bin/gcc-3.1.]]
注意，无论是前缀还是后缀，最好载字符串后加一个**短横线**，另外如果字符串中没有空格，可以不加引号。
**--program-transform-name=pattern**
Applies the `sed' script pattern to be applied to the names of programs to install in bindir (see above). pattern has to consist of one or more basic// `sed' editing commands//, separated by semicolons. For example, if you want the `gcc' program name to be transformed to the installed program /usr/local/bin/myowngcc and the `g++' program name to be transformed to /usr/local/bin/gspecial++ without changing other program names, you could use the pattern **--program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/'** to achieve this effect.
All three options can be //combined and used together//, resulting in more complex conversion patterns. As a basic rule, prefix (and suffix) are prepended (appended) __before__ further transformations can happen with a special transformation script pattern.
As currently implemented, this option __only takes effect for native builds(生成的程序的运行环境和当前一致)__; cross compiler binaries' names are not transformed even when a transformation is explicitly asked for by one of these options.
For native builds, some of the installed programs are __also installed with the target alias in front of their name__, as in `i686-pc-linux-gnu-gcc'. All of the above transformations happen __before__ the target alias is prepended to the name—so, specifying --program-prefix=foo- and program-suffix=-3.1, the resulting binary would be installed as /usr/local/bin///i686-pc-linux-gnu-foo-gcc-3.1//.
以上三个选项只适合native target(build), 对于cross build（target）无效，这是由于
**--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. (指的是本机的gcc在编译这个gcc源代码时，回到local-prefix指定的目录下的include目录下寻找header文件。)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(即将编译安装的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.
__ Do not specify /usr as the --with-local-prefix!__ The directory you use for --with-local-prefix must not contain any of the **system's** standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header file corrections made by the __fixincludes script__.
Indications are that people who use this option use it based on **mistaken ideas** of what it is for. People use it as if it specified where to install part of GCC. Perhaps they make this assumption because installing GCC creates the directory.
**--with-native-system-header-dir=dirname**
Specifies that dirname is the directory that contains native system header files, **rather than /usr/include**. This option is most useful if you are creating a compiler that should be __isolated__ from the system as much as possible. It is most commonly used with the **--with-sysroot **option and will cause GCC to search dirname inside the system root specified by that option.
**--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.
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', `ada', `libada', `libjava', `libgo', and `libobjc'. Note `libiberty' does 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-gnu-as**
Specify that the compiler should assume that the assembler it finds is the GNU assembler. However, this does not modify the rules to find an assembler and will result in confusion if the assembler found is not actually the GNU assembler. (Confusion may also result if the compiler finds the GNU assembler but has not been configured with --with-gnu-as.) If you have **more than one assembler** installed on your system, you may want to use this option in connection with **--with-as=pathname** or **--with-build-time-tools=pathname**.
The following systems are the only ones where it makes a difference whether you use the GNU assembler. On any other system, --with-gnu-as has** no effect**.
`hppa1.0-any-any'
`hppa1.1-any-any'
`sparc-sun-solaris2.any'
`sparc64-any-solaris2.any'
**--with-as=pathname**
Specify that the compiler(主机编译后**生成**的编译器) should use the assembler pointed to by pathname, rather than the one found by the standard rules to find an assembler, which are:
* Unless GCC is being built with a cross compiler, check the **libexec/gcc/target/version** directory. libexec defaults to exec-prefix/libexec; exec-prefix defaults to prefix, which defaults to /usr/local unless overridden by the --prefix=pathname switch described above. target is the __target system triple__, such as `sparc-sun-solaris2.7', and version denotes the GCC version, such as 3.0.
* If the target system is the same that you are building on, check operating system specific directories (e.g. /usr/ccs/bin on Sun Solaris 2).
* Check in the PATH for a tool whose name is **prefixed by the target system triple**.
* Check in the PATH for a tool whose name is **not prefixed** by the target system triple, if the host and target system triple are the same (in other words, we use a host tool if it can be used for the target as well).
You may want to use --with-as if no assembler is installed in the directories listed above, or if you have multiple assemblers installed and want to choose one that is not found by the above rules.
**--with-gnu-ld**
Same as --with-gnu-as but for the linker.
**--with-ld=pathname**
Same as --with-as but for the linker.
-**-with-stabs**
Specify that stabs debugging information should be used instead of whatever format the host normally uses. Normally GCC uses the same debug format as the host system.
On MIPS based systems and on Alphas, you must specify whether you want GCC to create the normal ECOFF debugging format, or to use BSD-style stabs passed through the ECOFF symbol table. The normal ECOFF debug format cannot fully handle languages other than C. BSD stabs format can handle other languages, but it only works with the GNU debugger GDB.
Normally, GCC uses the ECOFF debugging format by default; if you prefer BSD stabs, specify --with-stabs when you configure GCC.
No matter which default you choose when you configure GCC, the user can use the -gcoff and -gstabs+ options to specify explicitly the debug format for a particular compilation.
--with-stabs is meaningful on the ISC system on the 386, also, if --with-gas is used. It selects use of stabs debugging information embedded in COFF output. This kind of debugging information supports C++ well; ordinary COFF debugging information does not.
--with-stabs is also meaningful on 386 systems running SVR4. It selects use of stabs debugging information embedded in ELF output. The C++ compiler currently (2.6.0) does not support the DWARF debugging information normally used on 386 SVR4 platforms; stabs provide a workable alternative. This requires gas and gdb, as the normal SVR4 tools can not generate or interpret stabs.
--with-tls=dialect
Specify the default TLS dialect, for systems were there is a choice. For ARM targets, possible values for dialect are gnu or gnu2, which select between the original GNU dialect and the GNU TLS descriptor-based dialect.
**--disable-multilib**
Specify that **multiple target libraries** to support different target variants, calling conventions, etc. __should not__ be built. The default is to build a predefined set of them.
Some targets provide finer-grained control over which multilibs are built (e.g., --disable-softfloat):
arm-*-*
fpu, 26bit, underscore, interwork, biendian, nofmult.
m68*-*-*
softfloat, m68881, m68000, m68020.
mips*-*-*
single-float, biendian, softfloat.
powerpc*-*-*, rs6000*-*-*
aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian, sysv, aix.
**--with-multilib-list=list**
**--without-multilib-list**
Specify what multilibs to build. Currently only implemented for sh*-*-* and x86-64-*-linux*.
sh*-*-*
list is a comma separated **list of CPU** names. These must be of the form sh* or m* (in which case they match the compiler option for that processor). The list should not contain any endian options - these are handled by --with-endian.
If list is empty, then there will be no multilibs for extra processors. The multilib for the secondary endian remains enabled.
As a special case, if an entry in the list starts with a ! (exclamation point), then it is added to the list of excluded multilibs. Entries of this sort should be compatible with `MULTILIB_EXCLUDES' (once the leading ! has been stripped).
If --with-multilib-list is not given, then a default set of multilibs is selected based on the value of --target. This is usually the complete set of libraries, but some targets imply a more specialized subset.
Example 1: to configure a compiler for SH4A only, but supporting both endians, with little endian being the default:
--with-cpu=sh4a --with-endian=little,big --with-multilib-list=
Example 2: to configure a compiler for both SH4A and SH4AL-DSP, but with only little endian SH4AL:
--with-cpu=sh4a --with-endian=little,big \
--with-multilib-list=sh4al,!mb/m4al
x86-64-*-linux*
list is a comma separated list of m32, m64 and mx32 to enable 32-bit, 64-bit and x32 run-time libraries, respectively. If list is empty, then there will be no multilibs and only the default run-time library will be enabled.
If --with-multilib-list is not given, then only 32-bit and 64-bit run-time libraries will be enabled.
**--with-endian=endians**
Specify what endians to use. Currently only implemented for sh*-*-*.
endians may be one of the following:
big
Use big endian exclusively.
little
Use little endian exclusively.
big,little
Use big endian by default. Provide a multilib for little endian.
little,big
Use little endian by default. Provide a multilib for big endian.
**--enable-threads**
Specify that the target supports threads. This affects the Objective-C compiler and runtime library, and **exception handling** for other languages like C++ and Java. On some systems, this is the default.
In general, the best (and, in many cases, the only known) threading model available will be configured for use. Beware that on some systems, GCC has not been taught what threading models are generally available for the system. In this case, --enable-threads is an alias for __--enable-threads=single__.
**--disable-threads**
Specify that threading support should be disabled for the system. This is an alias for --enable-threads=single.
**--enable-threads=lib**
Specify that lib is the thread support library. This affects the Objective-C compiler and runtime library, and exception handling for other languages like C++ and Java. The possibilities for lib are:
aix
AIX thread support.
dce
DCE thread support.
lynx
LynxOS thread support.
mipssde
MIPS SDE thread support.
no
This is an alias for `single'.
posix
Generic POSIX/Unix98 thread support.
rtems
RTEMS thread support.
single
**Disable** thread support, should work for all platforms.
tpf
TPF thread support.
vxworks
VxWorks thread support.
win32
Microsoft Win32 API thread support.
**--enable-tls**
Specify that the target supports__ TLS (Thread Local Storage)__. Usually configure can correctly determine if TLS is supported. In cases where it guesses incorrectly, TLS can be explicitly enabled or disabled with --enable-tls or --disable-tls. This can happen if the assembler supports TLS but the C library does not, or if the assumptions made by the configure test are incorrect.
**--disable-tls**
Specify that the target does not support TLS. This is an alias for --enable-tls=no.
--with-cpu=cpu
--with-cpu-32=cpu
--with-cpu-64=cpu
Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC.
--with-schedule=cpu
--with-arch=cpu
--with-arch-32=cpu
--with-arch-64=cpu
--with-tune=cpu
--with-tune-32=cpu
--with-tune-64=cpu
--with-abi=abi
--with-fpu=type
--with-float=type
These configure options provide default values for the -mschedule=, -march=, -mtune=, -mabi=, and -mfpu= options and for -mhard-float or -msoft-float. As with --with-cpu, which switches will be accepted and acceptable values of the arguments depend on the target.
--with-mode=mode
Specify if the compiler should default to -marm or -mthumb. This option is only supported on ARM targets.
--with-stack-offset=num
This option sets the default for the -mstack-offset=num option, and will thus generally also control the setting of this option for libraries. This option is only supported on Epiphany targets.
--with-fpmath=isa
This options sets -mfpmath=sse by default and specifies the default ISA for floating-point arithmetics. You can select either `sse' which enables -msse2 or `avx' which enables -mavx by default. This option is only supported on i386 and x86-64 targets.
--with-divide=type
Specify how the compiler should generate code for checking for division by zero. This option is only supported on the MIPS target. The possibilities for type are:
traps
Division by zero checks use conditional traps (this is the default on systems that support conditional traps).
breaks
Division by zero checks use the break instruction.
--with-llsc
On MIPS targets, make -mllsc the default when no -mno-lsc option is passed. This is the default for Linux-based targets, as the kernel will emulate them if the ISA does not provide them.
--without-llsc
On MIPS targets, make -mno-llsc the default when no -mllsc option is passed.
--with-synci
On MIPS targets, make -msynci the default when no -mno-synci option is passed.
--without-synci
On MIPS targets, make -mno-synci the default when no -msynci option is passed. This is the default.
--with-mips-plt
On MIPS targets, make use of copy relocations and PLTs. These features are extensions to the traditional SVR4-based MIPS ABIs and require support from GNU binutils and the runtime C library.
--enable-__cxa_atexit
Define if you want to use __cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects. This is essential for fully standards-compliant handling of destructors, but requires __cxa_atexit in libc. This option is currently only available on systems with GNU libc. When enabled, this will cause -fuse-cxa-atexit to be passed by default.
--enable-gnu-indirect-function
Define if you want to enable the ifunc attribute. This option is currently only available on systems with GNU libc on certain targets.
--enable-target-optspace
Specify that target libraries should be optimized for code space instead of code speed. This is the default for the m32r platform.
--with-cpp-install-dir=dirname
Specify that the user visible cpp program should be installed in prefix/dirname/cpp, in addition to bindir.
--enable-comdat
Enable COMDAT group support. This is primarily used to override the automatically detected value.
--enable-initfini-array
Force the use of sections .init_array and .fini_array (instead of .init and .fini) for constructors and destructors. Option --disable-initfini-array has the opposite effect. If neither option is specified, the configure script will try to guess whether the .init_array and .fini_array sections are supported and, if they are, use them.
**--enable-build-with-cxx**
Build GCC using a C++ compiler rather than a C compiler. This is an __experimental option__ which may become the default in a later release.
--enable-build-poststage1-with-cxx
When __bootstrapping__, build stages 2 and 3 of GCC using a C++ compiler rather than a C compiler. Stage 1 is still built with a C compiler. This is **enabled by default** and may be disabled using --disable-build-poststage1-with-cxx.
--enable-maintainer-mode
The build rules that regenerate the Autoconf and Automake output files as well as the GCC master message catalog gcc.pot are normally disabled. This is because it can only be rebuilt if the complete source tree is present. If you have changed the sources and want to rebuild the catalog, configuring with --enable-maintainer-mode will enable this. Note that you need a recent version of the gettext tools to do so.
**--disable-bootstrap**
For a native build, the default configuration is to __perform a 3-stage bootstrap of the compiler__ when `make' is invoked, __testing that GCC can compile itself correctly__. If you want to disable this process, you can configure with --disable-bootstrap.
--enable-bootstrap
In special cases, you may want to perform a 3-stage build even if the target and host triplets are different. This is possible when the host can run code compiled for the target (e.g. host is i686-linux, target is i486-linux). Starting from GCC 4.2, to do this you have to configure explicitly with --enable-bootstrap.
**--enable-generated-files-in-srcdir**
Neither the .c and .h files that are generated from Bison and flex nor the info manuals and man pages that are built from the .texi files are present in the SVN development tree. When building GCC from that development tree, or from one of our snapshots, those generated files are placed in your build directory, which allows for the source to be in a readonly directory.
If you configure with --enable-generated-files-in-srcdir then those generated files will go into the source directory. This is mainly intended for generating release or prerelease tarballs of the GCC sources, since it is not a requirement that the users of source releases to have flex, Bison, or makeinfo.
--enable-version-specific-runtime-libs
Specify that runtime libraries should be installed in the compiler specific subdirectory (libdir/gcc) rather than the usual places. In addition, `libstdc++''s include files will be installed into libdir unless you overruled it by using --with-gxx-include-dir=dirname. Using this option is particularly useful if you intend to use several versions of GCC in parallel. This is currently supported by `libgfortran', `libjava', `libmudflap', `libstdc++', and `libobjc'.
__--enable-languages=lang1,lang2,...__
Specify that only a particular subset of compilers and their runtime libraries should be built. For a list of valid values for langN you can issue the following command in the gcc directory of your GCC source tree:
grep language= */config-lang.in
Currently, you can use any of the following: all, ada, c, c++, fortran, go, java, objc, obj-c++. Building the Ada compiler has special requirements, see below. If you do not pass this flag, or specify the option all, then all default languages available in the gcc sub-tree will be configured. Ada, Go and Objective-C++ are not default languages; the rest are.
--enable-stage1-languages=lang1,lang2,...
Specify that a particular subset of compilers and their runtime libraries should be built with the system C compiler during stage 1 of the bootstrap process, rather than only in later stages with the bootstrapped C compiler. The list of valid values is the same as for --enable-languages, and the option all will select all of the languages enabled by --enable-languages. This option is primarily useful for GCC development; for instance, when a development version of the compiler cannot bootstrap due to compiler bugs, or when one is debugging front ends other than the C front end. When this option is used, one can then build the target libraries for the specified languages with the stage-1 compiler by using make stage1-bubble all-target, or run the testsuite on the stage-1 compiler for the specified languages using make stage1-start check-gcc.
**--disable-libada**
Specify that the__ run-time libraries__ and tools used by GNAT should not be built. This can be useful for debugging, or for compatibility with previous Ada build procedures, when it was required to explicitly do a `make -C gcc gnatlib_and_tools'.
--disable-libssp
Specify that the run-time libraries for __stack smashing protection__ should not be built.
--disable-libquadmath
Specify that the GCC __quad-precision math library__ should not be built. On some systems, the library is required to be linkable when building the Fortran front end, unless --disable-libquadmath-support is used.
--disable-libquadmath-support
Specify that the Fortran front end and libgfortran do not add support for libquadmath on systems supporting it.
--disable-libgomp
Specify that the run-time libraries used by GOMP should not be built.
--with-dwarf2
Specify that the compiler should use DWARF 2 debugging information as the default.
**--enable-targets=all**
--enable-targets=target_list
Some GCC targets, e.g. powerpc64-linux, build __bi-arch__ compilers. These are compilers that are able to generate either 64-bit or 32-bit code. Typically, the corresponding 32-bit target, e.g. powerpc-linux for powerpc64-linux, only generates 32-bit code. This option enables the 32-bit target to be a bi-arch compiler, which is useful when you want a bi-arch compiler that defaults to 32-bit, and you are building a bi-arch or multi-arch binutils in a combined tree. On mips-linux, this will build a tri-arch compiler (ABI o32/n32/64), defaulted to o32. Currently, this option only affects **sparc-linux, powerpc-linux, x86-linux, mips-linux and s390-linux**.
--enable-secureplt
This option enables -msecure-plt by default for powerpc-linux. See “RS/6000 and PowerPC Options” in the main manual
--enable-cld
This option enables -mcld by default for 32-bit x86 targets. See “i386 and x86-64 Options” in the main manual
--enable-win32-registry
--enable-win32-registry=key
--disable-win32-registry
The --enable-win32-registry option enables Microsoft Windows-hosted GCC to look up installations paths in the registry using the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\key
key defaults to GCC version number, and can be overridden by the --enable-win32-registry=key option. Vendors and distributors who use custom installers are encouraged to provide a different key, perhaps one comprised of vendor name and GCC version number, to avoid conflict with existing installations. This feature is enabled by default, and can be disabled by --disable-win32-registry option. This option has no effect on the other hosts.
--nfp
Specify that the machine does not have a floating point unit. This option only applies to `m68k-sun-sunosn'. On any other system, --nfp has no effect.
--enable-werror
--disable-werror
--enable-werror=yes
--enable-werror=no
When you specify this option, it controls whether certain files in the compiler are built with -Werror in bootstrap stage2 and later. If you don't specify it, -Werror is turned on for the main development trunk. However it defaults to off for release branches and final releases. The specific files which get -Werror are controlled by the Makefiles.
**--enable-checking**
--enable-checking=list
When you specify this option, the compiler is built to perform internal consistency checks of the requested complexity. This does not change the generated code, but adds error checking within the compiler. This will slow down the compiler and may only work properly if you are building the compiler with GCC. This is `yes' by default when building from SVN or snapshots, but `release' for releases. The default for building the stage1 compiler is `yes'. More control over the checks may be had by specifying list. The categories of checks available are `yes' (most common checks `assert,misc,tree,gc,rtlflag,runtime'), `no' (no checks at all), `all' (all but `valgrind'), `release' (cheapest checks `assert,runtime') or `none' (same as `no'). Individual checks can be enabled with these flags `assert', `df', `fold', `gc', `gcac' `misc', `rtl', `rtlflag', `runtime', `tree', and `valgrind'.
The `valgrind' check requires the external valgrind simulator, available from http://valgrind.org/. The `df', `rtl', `gcac' and `valgrind' checks are very expensive. To disable all checking, `--disable-checking' or `--enable-checking=none' must be explicitly requested. Disabling assertions will make the compiler and runtime slightly faster but increase the risk of undetected internal errors causing wrong code to be generated.
--disable-stage1-checking
--enable-stage1-checking
--enable-stage1-checking=list
If no --enable-checking option is specified the stage1 compiler will be built with `yes' checking enabled, otherwise the stage1 checking flags are the same as specified by --enable-checking. To build the stage1 compiler with different checking options use --enable-stage1-checking. The list of checking options is the same as for --enable-checking. If your system is too slow or too small to bootstrap a released compiler with checking for stage1 enabled, you can use `--disable-stage1-checking' to disable checking for the stage1 compiler.
--enable-coverage
--enable-coverage=level
With this option, the compiler is built to collect self coverage information, every time it is run. This is for internal development purposes, and only works when the compiler is being built with gcc. The level argument controls whether the compiler is built optimized or not, values are `opt' and `noopt'. For coverage analysis you want to disable optimization, for performance analysis you want to enable optimization. When coverage is enabled, the default level is without optimization.
--enable-gather-detailed-mem-stats
When this option is specified more detailed information on memory allocation is gathered. This information is printed when using -fmem-report.
--with-gc
--with-gc=choice
With this option you can specify the **garbage collector** implementation used during the compilation process. choice can be one of `page' and `zone', where `page' is the default.
--enable-nls
--disable-nls
The --enable-nls option enables__ Native Language Support (NLS)__, which lets GCC output diagnostics in languages other than American English. Native Language Support is enabled by default if not doing a canadian cross build. The --disable-nls option disables NLS.
--with-included-gettext
If NLS is enabled, the --with-included-gettext option causes the build procedure to prefer its copy of GNU gettext.
--with-catgets
If NLS is enabled, and if the host lacks gettext but has the inferior catgets interface, the GCC build procedure normally ignores catgets and instead uses GCC's copy of the GNU gettext library. The --with-catgets option causes the build procedure to use the host's catgets in this situation.
--with-libiconv-prefix=dir
Search for libiconv header files in dir/include and libiconv library files in dir/lib.
--enable-obsolete
Enable configuration for an obsoleted system. If you attempt to configure GCC for a system (build, host, or target) which has been obsoleted, and you do not specify this flag, configure will halt with an error message.
All support for systems which have been obsoleted in one release of GCC is removed entirely in the next major release, unless someone steps forward to maintain the port.
--enable-decimal-float
--enable-decimal-float=yes
--enable-decimal-float=no
--enable-decimal-float=bid
--enable-decimal-float=dpd
--disable-decimal-float
Enable (or disable) support for the C decimal floating point extension that is in the IEEE 754-2008 standard. This is enabled by default only on PowerPC, i386, and x86_64 GNU/Linux systems. Other systems may also support it, but require the user to specifically enable it. You can optionally control which decimal floating point format is used (either `bid' or `dpd'). The `bid' (binary integer decimal) format is default on i386 and x86_64 systems, and the `dpd' (densely packed decimal) format is default on PowerPC systems.
--enable-fixed-point
--disable-fixed-point
Enable (or disable) support for C fixed-point arithmetic. This option is enabled by default for some targets (such as MIPS) which have hardware-support for fixed-point operations. On other targets, you may enable this option manually.
--with-long-double-128
Specify if long double type should be 128-bit by default on selected GNU/Linux architectures. If using --without-long-double-128, long double will be by default 64-bit, the same as double type. When neither of these configure options are used, the default will be 128-bit long double when built against GNU C Library 2.4 and later, 64-bit long double otherwise.
--with-gmp=pathname
--with-gmp-include=pathname
--with-gmp-lib=pathname
--with-mpfr=pathname
--with-mpfr-include=pathname
--with-mpfr-lib=pathname
--with-mpc=pathname
--with-mpc-include=pathname
--with-mpc-lib=pathname
If you do not have GMP (the GNU Multiple Precision library), the MPFR library and/or the MPC library installed in a __standard location__ and you want to build GCC, you can explicitly specify the directory where they are installed (`--with-gmp=gmpinstalldir', `--with-mpfr=mpfrinstalldir', `--with-mpc=mpcinstalldir'). The --with-gmp=gmpinstalldir option is shorthand for --with-gmp-lib=gmpinstalldir/lib and --with-gmp-include=gmpinstalldir/include. Likewise the --with-mpfr=mpfrinstalldir option is shorthand for --with-mpfr-lib=mpfrinstalldir/lib and --with-mpfr-include=mpfrinstalldir/include, also the --with-mpc=mpcinstalldir option is shorthand for --with-mpc-lib=mpcinstalldir/lib and --with-mpc-include=mpcinstalldir/include. If these shorthand assumptions are not correct, you can use the explicit include and lib options directly. You might also need to ensure the shared libraries can be found by the dynamic linker when building and using GCC, for example by setting the runtime shared library path variable (LD_LIBRARY_PATH on GNU/Linux and Solaris systems).
These flags are applicable to the host platform only. When building a cross compiler, they will not be used to configure target libraries.
--with-ppl=pathname
--with-ppl-include=pathname
--with-ppl-lib=pathname
--with-cloog=pathname
--with-cloog-include=pathname
--with-cloog-lib=pathname
If you do not have PPL (the Parma Polyhedra Library) and the CLooG libraries installed in a standard location and you want to build GCC, you can explicitly specify the directory where they are installed (`--with-ppl=pplinstalldir', `--with-cloog=clooginstalldir'). The --with-ppl=pplinstalldir option is shorthand for --with-ppl-lib=pplinstalldir/lib and --with-ppl-include=pplinstalldir/include. Likewise the --with-cloog=clooginstalldir option is shorthand for --with-cloog-lib=clooginstalldir/lib and --with-cloog-include=clooginstalldir/include. If these shorthand assumptions are not correct, you can use the explicit include and lib options directly.
These flags are applicable to the host platform only. When building a cross compiler, they will not be used to configure target libraries.
**--with-host-libstdcxx=linker-args**
If you are linking with a static copy of PPL, you can use this option to specify how the linker should find the standard C++ library used internally by PPL. Typical values of linker-args might be `-lstdc++' or `-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'. If you are linking with a shared copy of PPL, you probably do not need this option; shared library dependencies will cause the linker to search for the standard C++ library automatically.
--with-stage1-ldflags=flags
This option may be used to set linker flags to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with --disable-bootstrap. By default no special flags are used.
--with-stage1-libs=libs
This option may be used to set libraries to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with --disable-bootstrap. The default is the argument to --with-host-libstdcxx, if specified.
--with-boot-ldflags=flags
This option may be used to set linker flags to be used when linking stage 2 and later when bootstrapping GCC. If neither –with-boot-libs nor –with-host-libstdcxx is set to a value, then the default is `-static-libstdc++ -static-libgcc'.
--with-boot-libs=libs
This option may be used to set libraries to be used when linking stage 2 and later when bootstrapping GCC. The default is the argument to --with-host-libstdcxx, if specified.
--with-debug-prefix-map=map
Convert source directory names using -fdebug-prefix-map when building runtime libraries. `map' is a space-separated list of maps of the form `old=new'.
--enable-linker-build-id
Tells GCC to pass --build-id option to the linker for all final links (links performed without the -r or --relocatable option), if the linker supports it. If you specify --enable-linker-build-id, but your linker does not support --build-id option, a warning is issued and the --enable-linker-build-id option is ignored. The default is off.
--with-linker-hash-style=choice
Tells GCC to pass --hash-style=choice option to the linker for all final links. choice can be one of `sysv', `gnu', and `both' where `sysv' is the default.
--enable-gnu-unique-object
--disable-gnu-unique-object
Tells GCC to use the gnu_unique_object relocation for C++ template static data members and inline function local statics. Enabled by default for a native toolchain with an assembler that accepts it and GLIBC 2.11 or above, otherwise disabled.
--enable-lto
--disable-lto
Enable support for__ link-time optimization (LTO)__. This is enabled by default, and may be disabled using --disable-lto.
--with-plugin-ld=pathname
Enable an alternate linker to be used at link-time optimization (LTO) link time when -fuse-linker-plugin is enabled. This linker should have plugin support such as gold starting with version 2.20 or GNU ld starting with version 2.21. See -fuse-linker-plugin for details.
===== Cross-Compiler-Specific Options =====
The following options only apply to building cross compilers.
**--with-sysroot**
**--with-sysroot=dir（生成的编译器，会把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__. More specifically, this acts as if __--sysroot=dir__ was added to the default options of the built compiler(用编译好的编译器编译源文件时指定--sysroot=dir选项). 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__.
This option affects the system root for the compiler used to build **target libraries** (which runs on the build system) and the compiler **newly **installed with make install; it does **not affect** the compiler which is used to build GCC itself.(这个选项只会对生成的编译器有影响，不会影响正在编译编译器代码的主机编译器)
If you specify the --with-native-system-header-dir=dirname option then the compiler(编译后生成的编译器) will search that directory within dirname **for native system headers**__ rather than__ the default /usr/include.(生成的编译器只会在dir中搜索头文件)
**--with-build-sysroot**
**--with-build-sysroot=dir(当--prefix和实际安装的位置不一致时，可以使用这个选项)**
Tells GCC to consider dir as the system root (see --with-sysroot) while building target libraries, instead of the directory specified with --with-sysroot. This option is only useful __when you are already using --with-sysroot__. You can use --with-build-sysroot when you are configuring with --prefix set to a directory that is __different__ from the one in which you are installing GCC and your target libraries.
This option affects the system root for the compiler used to build target libraries (which runs on the build system); it does not affect the compiler which is used to build GCC itself.
If you specify the --with-native-system-header-dir=dirname option then the compiler will search that directory within dirname for native system headers rather than the default /usr/include.
**--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.
**--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'.
**--with-build-time-tools=dir**
Specifies where to find the set of __target tools__ (assembler, linker, etc.) that will be used while building GCC itself. This option can be useful if the directory layouts are different between the system you are building GCC on, and the system where you will deploy it.
For example, on an `ia64-hp-hpux' system, you may have the GNU assembler and linker in /usr/bin, and the native tools in a different path, and build a toolchain that expects to find the native tools in /usr/bin.
When you use this option, you should ensure that dir includes **ar, as, ld, nm, ranlib and strip **if necessary, and possibly objdump. Otherwise, GCC may use an inconsistent set of tools.
===== Java-Specific Options =====
The following option applies to the build of the Java front end.
--disable-libgcj
Specify that the run-time libraries used by GCJ should not be built. This is useful in case you intend to use GCJ with some other run-time, or you're going to install it separately, or it just happens not to build on your particular machine. In general, if the Java front end is enabled, the GCJ libraries will be enabled too, unless they're known to not work on the target platform. If GCJ is enabled but `libgcj' isn't built, you may need to port it; in this case, before modifying the top-level configure.in so that `libgcj' is enabled by default on this platform, you may use --enable-libgcj to override the default.
The following options apply to building `libgcj'.
General Options
--enable-java-maintainer-mode
By default the `libjava' build will not attempt to compile the .java source files to .class. Instead, it will use the .class files from the source tree. If you use this option you must have executables named ecj1 and gjavah in your path for use by the build. You must use this option if you intend to modify any .java files in libjava.
--with-java-home=dirname
This `libjava' option overrides the default value of the `java.home' system property. It is also used to set `sun.boot.class.path' to dirname/lib/rt.jar. By default `java.home' is set to prefix and `sun.boot.class.path' to datadir/java/libgcj-version.jar.
--with-ecj-jar=filename
This option can be used to specify the location of an external jar file containing the Eclipse Java compiler. A specially modified version of this compiler is used by gcj to parse .java source files. If this option is given, the `libjava' build will create and install an ecj1 executable which uses this jar file at runtime.
If this option is not given, but an ecj.jar file is found in the topmost source tree at configure time, then the `libgcj' build will create and install ecj1, and will also install the discovered ecj.jar into a suitable place in the install tree.
If ecj1 is not installed, then the user will have to supply one on his path in order for gcj to properly parse .java source files. A suitable jar is available from ftp://sourceware.org/pub/java/.
--disable-getenv-properties
Don't set system properties from GCJ_PROPERTIES.
--enable-hash-synchronization
Use a global hash table for monitor locks. Ordinarily, `libgcj''s `configure' script automatically makes the correct choice for this option for your platform. Only use this if you know you need the library to be configured differently.
--enable-interpreter
Enable the Java interpreter. The interpreter is automatically enabled by default on all platforms that support it. This option is really only useful if you want to disable the interpreter (using --disable-interpreter).
--disable-java-net
Disable java.net. This disables the native part of java.net only, using non-functional stubs for native method implementations.
--disable-jvmpi
Disable JVMPI support.
--disable-libgcj-bc
Disable BC ABI compilation of certain parts of libgcj. By default, some portions of libgcj are compiled with -findirect-dispatch and -fno-indirect-classes, allowing them to be overridden at run-time.
If --disable-libgcj-bc is specified, libgcj is built without these options. This allows the compile-time linker to resolve dependencies when statically linking to libgcj. However it makes it impossible to override the affected portions of libgcj at run-time.
--enable-reduced-reflection
Build most of libgcj with -freduced-reflection. This reduces the size of libgcj at the expense of not being able to do accurate reflection on the classes it contains. This option is safe if you know that code using libgcj will never use reflection on the standard runtime classes in libgcj (including using serialization, RMI or CORBA).
--with-ecos
Enable runtime eCos target support.
--without-libffi
Don't use `libffi'. This will disable the interpreter and JNI support as well, as these require `libffi' to work.
--enable-libgcj-debug
Enable runtime debugging code.
--enable-libgcj-multifile
If specified, causes all .java source files to be compiled into .class files in one invocation of `gcj'. This can speed up build time, but is more resource-intensive. If this option is unspecified or disabled, `gcj' is invoked once for each .java file to compile into a .class file.
--with-libiconv-prefix=DIR
Search for libiconv in DIR/include and DIR/lib.
--enable-sjlj-exceptions
Force use of the setjmp/longjmp-based scheme for exceptions. `configure' ordinarily picks the correct value based on the platform. Only use this option if you are sure you need a different setting.
--with-system-zlib
Use installed `zlib' rather than that included with GCC.
--with-win32-nlsapi=ansi, unicows or unicode
Indicates how MinGW `libgcj' translates between UNICODE characters and the Win32 API.
--enable-java-home
If enabled, this creates a JPackage compatible SDK environment during install. Note that if –enable-java-home is used, –with-arch-directory=ARCH must also be specified.
--with-arch-directory=ARCH
Specifies the name to use for the jre/lib/ARCH directory in the SDK environment created when –enable-java-home is passed. Typical names for this directory include i386, amd64, ia64, etc.
--with-os-directory=DIR
Specifies the OS directory for the SDK include directory. This is set to auto detect, and is typically 'linux'.
--with-origin-name=NAME
Specifies the JPackage origin name. This defaults to the 'gcj' in java-1.5.0-gcj.
--with-arch-suffix=SUFFIX
Specifies the suffix for the sdk directory. Defaults to the empty string. Examples include '.x86_64' in 'java-1.5.0-gcj-1.5.0.0.x86_64'.
--with-jvm-root-dir=DIR
Specifies where to install the SDK. Default is $(prefix)/lib/jvm.
--with-jvm-jar-dir=DIR
Specifies where to install jars. Default is $(prefix)/lib/jvm-exports.
--with-python-dir=DIR
Specifies where to install the Python modules used for aot-compile. DIR should not include the prefix used in installation. For example, if the Python modules are to be installed in /usr/lib/python2.5/site-packages, then –with-python-dir=/lib/python2.5/site-packages should be passed. If this is not specified, then the Python modules are installed in $(prefix)/share/python.
--enable-aot-compile-rpm
Adds aot-compile-rpm to the list of installed scripts.
--enable-browser-plugin
Build the gcjwebplugin web browser plugin.
--enable-static-libjava
Build static libraries in libjava. The default is to only build shared libraries.
ansi
Use the single-byte char and the Win32 A functions natively, translating to and from UNICODE when using these functions. If unspecified, this is the default.
unicows
Use the WCHAR and Win32 W functions natively. Adds -lunicows to libgcj.spec to link with `libunicows'. unicows.dll needs to be deployed on Microsoft Windows 9X machines running built executables. libunicows.a, an open-source import library around Microsoft's unicows.dll, is obtained from http://libunicows.sourceforge.net/, which also gives details on getting unicows.dll from Microsoft.
unicode
Use the WCHAR and Win32 W functions natively. Does not add -lunicows to libgcj.spec. The built executables will only run on Microsoft Windows NT and above.
===== AWT-Specific Options =====
--with-x
Use the X Window System.
--enable-java-awt=PEER(S)
Specifies the AWT peer library or libraries to build alongside `libgcj'. If this option is unspecified or disabled, AWT will be non-functional. Current valid values are gtk and xlib. Multiple libraries should be separated by a comma (i.e. --enable-java-awt=gtk,xlib).
--enable-gtk-cairo
Build the cairo Graphics2D implementation on GTK.
--enable-java-gc=TYPE
Choose garbage collector. Defaults to boehm if unspecified.
--disable-gtktest
Do not try to compile and run a test GTK+ program.
--disable-glibtest
Do not try to compile and run a test GLIB program.
--with-libart-prefix=PFX
Prefix where libart is installed (optional).
--with-libart-exec-prefix=PFX
Exec prefix where libart is installed (optional).
--disable-libarttest
Do not try to compile and run a test libart program.
===== Overriding configure test results =====
Sometimes, it might be necessary to override the result of some configure test, for example in order to ease porting to a new system or work around a bug in a test. The toplevel configure script provides three variables for this:
build_configargs
The contents of this variable is passed to all build configure scripts.
host_configargs
The contents of this variable is passed to all host configure scripts.
target_configargs
The contents of this variable is passed to all target configure scripts.
In order to avoid shell and make quoting issues for complex overrides, you can pass a setting for CONFIG_SITE and set variables in the site file.
Return to the GCC Installation page
For questions related to the use of GCC, please consult these web pages and the GCC manuals. If that fails, the gcc-help@gcc.gnu.org mailing list might help. Comments on these web pages and the development of GCC are welcome on our developer list at gcc@gcc.gnu.org. All of our lists have public archives.
Copyright (C) Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
These pages are maintained by the GCC team. Last modified 2011-11-23.

2437
Zim/Utils/make.txt
View File

File diff suppressed because it is too large Load Diff

68
Zim/Utils/工具链/autoconf---automake.txt
View File

@@ -24,7 +24,6 @@ http://www.ibm.com/developerworks/cn/linux/l-makefile/
假设src是我们源文件目录，include目录存放其他库的头文件，lib目录存放用到的库文件，然后开始按模块存放，每个模块都有一个对应的目录，模块下再分子模块，如apple、orange。每个子目录下又分core，include，shell三个目录，其中core和shell目录存放.c文件，include的存放.h文件，其他类似。
样例程序功能：基于多线程的数据读写保护（联系作者获取整个autoconf和automake生成的Makefile工程和源码，E-mail：normalnotebook@126.com）。
===== 工具简介 =====
@@ -53,10 +52,10 @@ flat类型是最简单的，deep类型是最复杂的。不难看出，我们的
首先进入 project 目录，在该目录下运行一系列命令，创建和修改几个文件，就可以生成符合**该平台**的Makefile文件，操作过程如下：
1) 运行autoscan命令
2) 将configure.scan 文件重命名为configure.in，并修改configure.in文件
2) 将configure.scan 文件重命名为configure.in(新版本的autoscan使用的是.__ac__扩展名)，并修改configure.in(或.ac)文件
3) 在**project目录**下新建Makefile.am文件，并在**core和shell**目录下也新建makefile.am文件
4) 在project目录下新建NEWS、 README、 ChangeLog 、AUTHORS文件
5) 将/usr/share/automake-1.X/目录下的depcomp和complie文件拷贝到本目录下
5) 将/usr/share/automake-1.X/目录下的**depcomp**和**complie**文件拷贝到本目录下。depcomp脚本用于automake自动解决依赖关系（其实是通过调用GCC来编译程序，然后将结果反馈给automake，用于产生依赖。）。
6) 运行aclocal命令
7) 运行autoconf命令
8) 运行automake -a命令
@@ -64,19 +63,20 @@ flat类型是最简单的，deep类型是最复杂的。不难看出，我们的
可以通过图2看出产生Makefile的流程，如图所示：
图 2生成Makefile流程图
{{./2.gif}}
图 2生成Makefile流程图
===== Configure.in的八股文(整个工程只需一个该文件) =====
当我们利用autoscan工具生成confiugre.scan文件时，我们需要将confiugre.scan重命名为confiugre.in文件。confiugre.in调用__一系列autoconf宏__来测试程序需要的或用到的__特性__是否存在以及这些特性的功能。
当我们利用autoscan工具生成confiugre.scan文件时，我们需要将confiugre.scan重命名为confiugre.in(或.ac)文件。confiugre.in调用__一系列autoconf宏__来测试程序需要的或用到的__特性__是否存在以及这些特性的功能。
下面我们就来目睹一下confiugre.scan的庐山真面目：
# Process this file with autoconf to produce a **configure script**.
AC_PREREQ(2.59)
**AC_INIT**(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
**AC_INIT**(FULL-PACKAGE-N AME, VERSION, BUG-REPORT-ADDRESS)
AC_CONFIG_SRCDIR([config.h.in])
**AC_CONFIG_HEADER**([config.h])
# Checks for programs.
@@ -88,7 +88,8 @@ AC_CHECK_LIB([pthread], [main]) #main为在库pthread中检查的函数名。
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
**AC_OUTPUT**
#上述所有的[]中的内容需要自定义。
#上述所有的[ ]中的内容需要自定义。
autoconf和automake 一般__不向后兼容__，例如autoconfig v1.9的configure.ac文件不一定适用于autoconfig v2.2
每个configure.scan文件都是以AC_INIT开头，以AC_OUTPUT结束。我们不难从文件中看出confiugre.in文件的一般布局：
@@ -110,7 +111,6 @@ AC_OUTPUT
$mv configure.scan configure.in
$vim configure.in
修改后的结果如下：
@@ -119,16 +119,18 @@ $vim configure.in
AC_PREREQ(2.59)
AC_INIT(test, 1.0, normalnotebook@126.com)
**AM_INIT_AUTOMAKE**(test,1.0)
**AM_INIT_AUTOMAKE**(test,1.0) //如果生成makefile，则该宏是必须的。
AC_CONFIG_**SRCDIR**([src/ModuleA/apple/core/test.c])
AM_CONFIG_HEADER(config.h)
# Checks for programs.
AC_PROG_CC
AC_PROG___RANLIB__
# Checks for libraries.
# FIXME: Replace `main' with a function in `-lpthread':
AC_CHECK_LIB([pthread], [**pthread_rwlock_init**]) #库中的函数名称
AC_PROG___RANLIB__
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
@@ -137,15 +139,13 @@ AC_PROG___RANLIB__
src/ModuleA/apple/core/Makefile
src/ModuleA/apple/shell/Makefile
]) #列出项目中所有需要被configure脚本替换的makefile.in的位置。
注意：在新版本的autoconf工具中，AC_OUTPUT(files...)的用法已经过时了，推荐的用法是
[Macro] AC_OUTPUT ([file]. . . , [extra-cmds], [init-cmds])
The use of AC_OUTPUT with arguments is deprecated. This obsoleted interface is
equivalent to:
__AC_CONFIG_FILES(file...)__
AC_CONFIG_COMMANDS([default],
extra-cmds, init-cmds)
AC_OUTPUT
[Macro] AC_OUTPUT ([file]. . . , [extra-cmds], [init-cmds])
The use of AC_OUTPUT with arguments is deprecated. This obsoleted interface is equivalent to:
__AC_CONFIG_FILES(file...)__
AC_CONFIG_COMMANDS([default], extra-cmds, init-cmds)
AC_OUTPUT //用于指示生成config.status，由它负责替换(生成)AC_CONFIG_FILES中指定的文件。
其中要将AC_CONFIG_HEADER([config.h])修改为：AM_CONFIG_HEADER(**config.h**), 并加入AM_INIT_AUTOMAKE(test,1.0)。由于我们的测试程序是基于多线程的程序，所以要加入AC_PROG_RANLIB，不然运行automake命令时会出错。在AC_OUTPUT输入要创建的Makefile文件名。
@@ -157,57 +157,50 @@ AC_OUTPUT
Autoconf提供了很多__内置宏来做相关的检测__，限于篇幅关系，我们在这里对其他宏不做详细的解释，具体请参看参考文献1和参考文献2，也可参看autoconf信息页。
autconf工具生成的configure脚本，会检查系统的特性，然后将结果反馈到makefile中，这是通过替换makefile.am中的相关变量值达到的。
===== 实战Makefile.am =====
Makefile.am是一种**比Makefile更高层次的规则，其内容是一些变量定义，采用的是makefile的语法格式，所起其中也可以包含makefile指令**。只需指定要__生成什么__目标，它由__哪些源文件__生成，要__安装到__什么目录等构成。
表一列出了可执行文件、静态库、头文件和数据文件，四种书写Makefile.am文件个一般格式。
表一 列出了可执行文件、静态库、头文件和数据文件，四种书写Makefile.am文件个一般格式:
表 1Makefile.am一般格式
{{./4.gif}}
表 1Makefile.am一般格式
注意：上面的include_FEADERS中的include是可变部分(见后文示例)，会被安装到系统的头文件目录中。
对于可执行文件和静态库类型，如果只想编译，不想安装到系统中，可以用**noinst_PROGRAMS**代替bin_PROGRAMS，**noinst_LIBRARIES**代替lib_LIBRARIES。
Makefile.am还提供了一些**全局变量**供所有的目标体使用：
表 2 Makefile.am中可用的全局变量
{{./5.gif}}
表 2 Makefile.am中可用的全局变量
在Makefile.am中__尽量使用相对路径__，系统预定义了两个基本路径：
表 3Makefile.am中可用的路径变量
{{./6.gif}}
表 3Makefile.am中可用的路径变量
在上文中我们提到过安装路径，automake设置了默认的安装路径：
1) 标准安装路径
默认安装路径为：$(prefix) = /usr/local，可以通过./configure **--prefix**=<new_path>的方法来覆盖。
其它的预定义目录还包括：bindir = $(prefix)/bin, libdir = $(prefix)/lib, **datadir** = $(prefix)/share, **sysconfdir** = $(prefix)/etc等等。
2) 定义一个新的安装路径
比如test, 可定义testdir = $(prefix)/test, 然后test_DATA =test1 test2，则test1，test2会作为数据文件安装到$(prefix)/test目录下。
我们首先需要在工程//顶层目录//下（即project/）创建一个Makefile.am来指明包含的子目录：
__SUBDIRS__=src/lib src/ModuleA/apple/shell src/ModuleA/apple/core
__SUBDIRS__=src/lib src/ModuleA/apple/shell src/ModuleA/apple/core
**CURRENTPATH**=$(shell /bin/pwd) #makefile.am采用的是makefile语法
**INCLUDES=**-I$(CURRENTPATH)/src/include -I$(CURRENTPATH)/src/ModuleA/apple/include
**export **INCLUDES
SUBDIRS指出了子目录中包含makefile.am。
由于每个源文件都会用到相同的头文件，所以我们在最顶层的Makefile.am中包含了编译源文件时所用到的头文件，并导出，见蓝色部分代码。
SUBDIRS指出了子目录中包含makefile.am。由于每个源文件都会用到相同的头文件，所以我们在最顶层的Makefile.am中包含了编译源文件时所用到的头文件，并导出.
我们将lib目录下的swap.c文件编译成libswap.a文件，被apple/shell/apple.c文件调用，那么lib目录下的Makefile.am如下所示：
**noinst**_LIBRARIES=__libswap.a__
libswap_a_SOURCES=swap.c
INCLUDES=__-I$(top_srcdir)__/src/includ
细心的读者可能就会问：怎么表1中给出的是bin_LIBRARIES，而这里是noinst_LIBRARIES？这是因为如果只想编译，而不想安装到系统中，就用noinst_LIBRARIES代替bin_LIBRARIES，对于可执行文件就用noinst_PROGRAMS代替bin_PROGRAMS。对于安装的情况，库将会安装到$(prefix)/lib目录下，可执行文件将会安装到${prefix}/bin。如果想安装该库，则Makefile.am示例如下：
bin_LIBRARIES=libswap.a
@@ -218,7 +211,7 @@ INCLUDES=-I$(top_srcdir)/src/include
最后两行的意思是将swap.h安装到${prefix}/include /swap目录下。
接下来，对于**可执行文件类型**的情况，我们将讨论如何写Makefile.am？对于编译apple/core目录下的文件，我们写成的Makefile.am如下所示：
接下来，对于**可执行文件类型**的情况，我们将讨论如何写Makefile.am。对于编译apple/core目录下的文件，我们写成的Makefile.am如下所示：
noinst_PROGRAMS=test
test_SOURCES=test.c
@@ -229,7 +222,7 @@ DEFS+=-D_GNU_SOURCE
DEFS变量继承自autoconf，其内容会传给编译器，作为编译标志。
由于我们的test.c文件在**链接时**，需要apple.o和libswap.a文件，所以我们需要在test_LDADD中包含这两个文件。对于Linux下的信号量/读写锁文件进行编译，需要在编译选项中指明-D_GNU_SOURCE，所以在test_LDFLAGS中指明。而test_LDFLAGS只是链接时的选项，**编译时同样需要指明该选项**，所以需要__DEFS来指明编译选项__，由于DEFS**已经有初始值**，所以这里用+=的形式指明。从这里可以看出，Makefile.am中的语法与Makefile的语法一致，也可以采用条件表达式。如果你的程序还包含其他的库，除了用AC_CHECK_LIB宏来指明外，还可以用LIBS来指明。
由于我们的test.c文件在**链接时**，需要apple.o和libswap.a文件，所以我们需要在test_LDADD中包含这两个文件。对于Linux下的信号量/读写锁文件进行编译，需要在编译选项中指明-D_GNU_SOURCE，所以在test_LDFLAGS中指明。而test_LDFLAGS只是链接时的选项，**编译时同样需要指明该选项**，所以需要__DEFS来指明编译选项__，由于DEFS**已经有初始值**，所以这里用__+=__的形式指明。从这里可以看出，Makefile.am中的语法与Makefile的语法一致，也可以采用条件表达式。如果你的程序还包含其他的库，除了用AC_CHECK_LIB宏来指明外，还可以用LIBS来指明。
如果你只想编译某一个文件，那么Makefile.am如何写呢？这个文件也很简单，写法跟可执行文件的差不多，如下例所示：
@@ -237,7 +230,6 @@ noinst_PROGRAMS=apple
apple_SOURCES=apple.c
DEFS+=-D_GNU_SOURCE
我们这里只是欺骗automake，假装要生成apple文件，让它为我们**生成依赖关系和执行命令**。所以当你运行完automake命令后，然后修改apple/shell/下的**Makefile.in**文件，直接将LINK语句删除，即：
…….
@@ -245,8 +237,6 @@ clean-noinstPROGRAMS:
-test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS)
apple$(EXEEXT): $(apple_OBJECTS) $(apple_DEPENDENCIES)
@rm -f apple$(EXEEXT)
#$(LINK) $(apple_LDFLAGS) $(apple_OBJECTS) $(apple_LDADD) $(LIBS)
…….
#$(LINK) $(apple_LDFLAGS) $(apple_OBJECTS) $(apple_LDADD) __$(LIBS)__
通过上述处理，就可以达到我们的目的。从图1中不难看出为什么要修改Makefile.in的原因，而不是修改其他的文件。

84
Zim/Utils/工具链/autoconf---automake/Autoconf学习笔记.txt
View File

@@ -7,35 +7,33 @@ Created Thursday 14 June 2012
http://lyanry.itpub.net/
**Autoconf是什么？**
一 位物理学家、一位工程师和一位计算机科学家，三个人在讨论上帝是个什么样的人。物理学家说：“它老人家肯定是物理学家，因为在创世之初，上帝制造了光；你 们是知道的，麦克斯韦方程，电磁波的波粒二相性，相对论……“。工程师不干了：“它老人家肯定是一位工程师，因为在创造光之前，它把混沌分成了陆地和水； 开展了一项浩大的工程来处理泥浆，并从液体中分离出固体……“这时，只听得计算机科学家大吼：“呔！你所谓的‘混沌’是从哪里来的呢，呀？”
实际上，如果你从事__跨平台软件开发__工作，你就会发现不同系统之间存在众多微妙或巨大的差异，这使得程序顺利地通过编译困难重重，因为不同的系统仅接受适合自身的程序代码。而要向不同的系统提供相应的程序代码，是很难实现的事情，因此__POSIX出现__了，它好像一个理想中的系统，__程序员们为该系统编程__，然后使用 一个工具伪装为履行POSIX标准的用户机器，这样就能保证最终的源代码可以在不同平台（符合POSIX标准的）上编译。这个工具就是Autoconf （即本文开头那个计算机科学家所谓的‘混沌’）。
Autoconf 的任务就是帮助软件开发人员研究用户所用的系统，分析其是否符合POSIX标准，并提供相应解决方法。显然，要检测用户的机器，就需要运行一个检查器。因 为这个检查器的任务是去发现系统缺陷的，所以它必须具备绝对的跨平台运行能力。Bourne shell是最合适的一种语言，可以__用它来写configure作为检查器__。不过，Bourne shell不具备函数编程功能，用它来写较为复杂的检查器，就像用汇编语言编程一样困难。这样，类似于高级语言及其编译器被发明出来取代汇编语言那样， David J.MacKenzie发明了Autoconf语言及autoconf程序来替代普通的用Bourne shell写的检查器程序了。
**Autoconf初步(1)**
**autoconf软件包安装的工具**
autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate 和 ifnames
__Autoconf 仅仅是一个基于M4开发的库，提供了一套宏语言，用于检测库、程序等是否存在__。因为M4过于低等且Autoconf目的在于生成Bourne shell脚本，因此其高于M4。将Autoconf代码扩展为Bourne shell脚本很简单，可以使用“autom4te --language=autoconf“，也可以直接使用”autoconf“命令。autom4te和autoconf来自于[[../autoconf软件包.txt|autoconf软件包]]。
**Autoconf初步(1)**
__Autoconf 仅仅是一个基于M4开发的库，提供了一套宏语言，用于检测库、程序等是否存在__。因为M4过于低等且Autoconf目的在于生成Bourne shell脚本，因此其高于M4。
将Autoconf代码扩展为Bourne shell脚本很简单，可以使用“autom4te --language=autoconf“，也可以直接使用”autoconf“命令。autom4te和autoconf来自于autoconf软件包。
所有Autoconf脚本都要由__AC_INIT宏__开始：
//AC_INIT宏//
AC_INIT(package, version, [bug-report-address])
AC_INIT的参数列表中，package为预编译的软件包名，version表示其版本号。bug-report-address是可选参数，它通常是一个Email地址，用于用户向该Email地址发送bug报告。
下面是一份最简单的Autoconf脚本：
//auditor.ac//
AC_INIT(Auditor, 1.0)
下面使用autoconf工具，将auditor.ac脚本转换为Bourne shell脚本：
//Autoconf脚本的转换与使用//
$ autom4te //-l autoconf -o auditor a//uditor.ac #或autoconf -o auditor auditor.ac
$ ./auditor #在shell中执行生成的auditor脚本
$ ./auditor --version
@@ -48,14 +46,13 @@ AC_INIT的参数列表中，package为预编译的软件包名，version表示
许多软件是用C语言开发的，因此需要C编译器；__AC_PROG_CC宏__可以检测系统中是否存在C编译器。下面将auditor.ac修改为：
//[code4]auditor.ac//
//auditor.ac//
AC_INIT(Auditor, 1.0)
AC_PROG_CC
将修改后的auditor.ac转换为Boune shell脚本后并执行，如下：
//[code5]auditor.ac//
//auditor.ac//
$autoconf -o auditor auditor.ac
$ ./auditor
@@ -69,47 +66,40 @@ AC_INIT的参数列表中，package为预编译的软件包名，version表示
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
如何对AC_PROG_CC的运行结果加以利用呢？在Autoconf的工作流程中，AC_PROG_CC总是在Autoconf基于一些模板文件生成新文件之前运行。譬如，一旦对你的系统完成了全面检查，__Autoconf会根据对系统的检查结果将所有的'Makefile.in’模板转化为 ‘Makefile‘文件__。这个过程叫做软件包的‘configuring‘，传统的做法是由Autoconf根据‘configure.ac‘生成 configure脚本来实现的。
如何对AC_PROG_CC的运行结果加以利用呢？
autoconf将用M4语言编写的config.ac文件展开为一shell脚本，默认名称为__configure__。configure是一个标准的bash脚本，不依赖于autoconf和M4。执行configure脚本时，它会执行系统特性检查，该检查内容和结果会记录在__config.log__文件中。configure脚本最后会生成config.status脚本，接着执行它。config.status脚本将configure检查到的系统特性写入到一些环境变量中，然后读取各makefile.am模板文件(由config.ac中的AC_CONFIG_FILES宏指定)，替换其中的变量值，最终生成各个makefile。
**Autoconf初步(2)**
将auditor脚本变为系统编译环境配置脚本仅需要两个宏调用：
//[code1]AC_CONFIG_FILES宏//
//AC_CONFIG_FILES宏//
AC_CONFIG_FILES(file……, [command])
在AC_CONFIG_FILES宏中列出需要生成（替换）的文件是一个推荐的做法，AC_OUTPUT不需要参数，只用于指示生成config.status脚本，该脚本__实际负责__替换文件
中的变量引用。
在AC_CONFIG_FILES宏中的file部分用于指定需要生成的文件及其路径名(如/tmp/src/demo/Makefile)，同时该目录中需要有一个同名的且后缀名为.in的模板文件如/tmp/src/demo/Makefile.in, 而该Makefile.in文件是由automake工具根据Makefile.am文件生成的。
‘file’ 参数指要创建的文件，该文件复制于一份输入文件（默认为‘file.in’），并替换掉输出变量值。‘file’就是一份输出文件，称之为__系统编译环境配置文件__更准确一些。譬如，若‘FOO’是一个输出变量，而它的值为‘Bar’，那么在文件‘file.in’中出现的所有‘__@FOO@’__，在输出文件中都 会被替换为‘Bar’。
Makefile.am文件和autoconf.ac文件一样都是由程序员自己书写的，编写autoconf.ac文件使用的是预定义的用于系统特性检查M4宏；而编写Makefile.am文件时使用的是类似于makefile语法，但是相对高级。AC_OUTPUT不需要参数，只用于指示生成config.status脚本，该脚本__实际负责__替换模板文件中的变量引用。譬如，若‘FOO’是一个输出变量，而它的值为‘Bar’，那么在文件‘file.in’中出现的所有‘__@FOO@’__，在输出文件中都 会被替换为‘Bar’。
可选参数‘command’表示如果有必要，一旦文件创建完毕，也可以运行一些shell命令的。
//[code2]AC_OUTPUT//
//AC_OUTPUT//
AC_OUTPUT
这个宏用于完成所有输出（创建系统编译环境配置文件，输出头文件等等）。
下面对这两个宏的应用作简单演示：
//[code3]输入文件which-cc.in//
//输入模板文件which-cc.in//
#! @SHELL@
echo "cc is @CC@"
//[code4]Autoconf configure//
//Autoconf configure//
AC_INIT(Sample, 1.0)
AC_PROG_CC
AC_CONFIG_FILE([which-cc],[chmod +x which-cc])
AC_CONFIG_FILE([**which-cc**],[chmod +x which-cc])
AC_OUTPUT
configure脚本生成及其运行结果如下：
//[code5]configure脚本生成及其运行结果//
$ autoconf
$ ls
autom4te.cache configure __configure.ac__ configure.ac~ __which-cc.in__
@@ -123,7 +113,7 @@ configure脚本生成及其运行结果如下：
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
configure: creating //./config.status//
configure: creating **./config.status**
__config.status:__ creating which-cc
$ cat which-cc
#! /bin/sh
@@ -132,30 +122,28 @@ configure脚本生成及其运行结果如下：
可能你会纳闷configure脚本运行时生成了一个config.status文件，这是个什么东东呢？事实上，__configure仅仅是一个检查器：它本身不执行任何配置行为，它所创建的config.status会进行配置工作。__
**Autoconf初步(3)**
对configure.ac脚本的处理，输出的不仅仅有系统编译环境配置文件（即makefile），__也可以向C程序提供检查结果，表现为输出一个头文件__，其所提供的信息通常是简单的__编译预处理宏定义列表__。
对configure.ac脚本的处理，输出的不仅仅有系统编译环境配置文件，__也可以向C程序提供检查结果，表现为输出一个头文件__，其所提供的信息通常是简单的__编译预处理宏定义列表__。
[code1]**AC_CONFIG_HEADERS**
**AC_CONFIG_HEADERS**
AC_CONFIG_HEADERS(file……, [command])
和配置脚本文件的输出一样，输出的头文件也要从一份模板文件中复制内容，__这份模板文件中定义了CPP输出符号__。对于输出的头文件，比较传统的命名是 config.h，其模板文件名模认为config.h.in。对于一些操作系统，可能模板文件名中两个句点的文件命名方式不被支持，可以采用 config.hin或config_h.in来代替，然后在AC_CONFIG_HEADERS标明config.h与该模板文件的依赖关系即可，如： AC_CONFIG_HEADERS(config.h:config.hin)。
和配置脚本文件的输出一样，输出的头文件也要从一份模板文件中复制内容，__这份模板文件中定义了将向CPP输出的符号__。对于输出的头文件，比较传统的命名是 **config.h**，其模板文件名模认为__config.h.in__。对于一些操作系统，可能模板文件名中两个句点的文件命名方式不被支持，可以采用 config.hin或config_h.in来代替，然后在AC_CONFIG_HEADERS标明config.h与该模板文件的依赖关系即可，如： AC_CONFIG_HEADERS(config.h:config.hin)。
AC_CONFIG_HEADERS中的命令行参数表示如果有必要，可以调用一些shell命令。
通常在‘configure.ac’中对软件包的名称和版本作出声明，虽然如此，还需要为__软件包的命令行选项__‘--help‘提供有关软件包名称及版本号确切的应答，__主程序__就必须知道当前软件包的名称及其版本号(编程时是不知道的，因为这个是可配置的变量)，这个可以由配置脚本生成config.h文件来实现：
通常在‘configure.ac’中对软件包的名称和版本作出声明，虽然如此，还需要为__软件包中的主程序命令行选项__‘--help‘提供有关软件包名称及版本号确切的应答，__主程序代码__就必须知道当前软件包的名称及其版本号，但是__在编写主程序代码__时是不知道的，因为这个是可配置的变量。为了解决这个问题，开发者可以提供一个header.h.in__模板文件__，其中包含了多个类似于
#undef PACKAGE_BUGREPORT
的编译预处理命令，然后在主程序中include这个**与模板文件对应的头文件如header.h**。在编译配置代码的时候，由配置脚本(configure->config.status)负责根据收集到的系统和用户信息，修改header.h.in文件中的相应定义，最后生成主程序中引用的header.h文件。
为生成这样的头文件，对上回书中的configure.ac文件再度修改，如下：
[code2]configure.ac
configure.ac
AC_INIT(Audit, 1.1, lyanry@gmail.com)
AC_CONFIG_HEADERS(config.h)
__AC_CONFIG_HEADERS(config.h)__
AC_OUTPUT
下面是__config.h文件的模板config.h.in__:
[code3]config.h.in
config.h.in
/*定义bug报告发送地址*/
#undef PACKAGE_BUGREPORT
@@ -168,14 +156,16 @@ AC_CONFIG_HEADERS中的命令行参数表示如果有必要，可以调用一些
/*定义软件包版本号*/
#undef PACKAGE_VERSION
模板文件中的符号定义为#undef，这是因为当配置脚本没有检查到相应的符号配置值时不会修改相应的预处理定义。
下面对configure.ac进行处理，生成configure脚本，//运行configure脚本即可生成config.h文件(前提是config.h.in中的变量名称必须是autoconf可识别的)//：
[code4]生从configure及其运行结果
从configure及其运行结果：
[lyanry@lyanry sample]$ autoconf
[lyanry@lyanry sample]$ ./configure
configure: creating ./config.status
config.status: creating config.h
config.status: creating **config.h**
[lyanry@lyanry sample]$ cat config.h
/* config.h. Generated by configure. */
/*定义bug报告发送地址*/
@@ -190,13 +180,9 @@ AC_CONFIG_HEADERS中的命令行参数表示如果有必要，可以调用一些
#define PACKAGE_VERSION "1.0"
**Autoconf初步(4)**
上 一节，编译环境配置头文件模板config.h.in文件是手动编辑的，实际上它__可以很容易地由‘configure.ac’文件导出__，这通过检索__所有__已定义的预处理符号，并在其前冠以‘#undef’，然后再自动粘贴相应的标准注释，最后输出‘config.h.in’。用于完成这一过程的工具是 __autoheader__。configure.ac中定义的一些宏用于检查系统环境，它会将检查到的结果（库是否存在，版本号，软件路径及名称）写入到一些__特定的变量__中，这些变量可以被makefile.in引用，也可以__被源代码作为条件编译的参数__使用(常见的做法是将所有的这些变量以宏定义的形式写入到config.h文件中，然后__源程序include该头文件即可__)。
上 一节，编译环境配置头文件模板config.h.in文件是手动编辑的，实际上它__可以很容易地由‘configure.ac’文件导出__，这通过检索所有已定义的预处理符号，并在其前冠以‘#undef’，然后再自动粘贴相应的标准注释，最后输出‘config.h.in’。用于完成这一过程的工具是 __autoheader__。configure.ac中定义的一些宏用于检查系统环境，它会将检查到的结果（库是否存在，版本号，软件路径及名称）写入到一些__特定的变量__中，这些变量可以被makefile.in引用，也可以被源代码作为条件编译的参数使用(常见的做法是将所有的这些变量以宏定义的形式写入到config.h文件中，然后__源程序include该头文件即可__)。
[code1]autoheader用法
autoheader用法
$ rm config.h.in
$ autoheader
$ cat config.h.in
@@ -217,9 +203,9 @@ AC_CONFIG_HEADERS中的命令行参数表示如果有必要，可以调用一些
/* Define to the version of this package. */
#undef PACKAGE_VERSION
本文虽然在讲述Autoconf的初步应用，但依然需要运行两个程序，它们必须按次序运行？（并非如此）。我要在什么时机运行它们？（事实上，每次 'configure.ac'或其依赖文件发生更改之时都要运行这两个程序）。还有没有其他程序也像这样？（当然，automake， libtoolize，gettextize，aclocal……都这般运行）它们的运行次序是否也任意？（是的，本质上皆如此）。实际上，本文与其是讲Autoconf的初步使用，不如说是讲述autoreconf的初步使用：后者囊括了Autoconf中的各类工具，知道在什么情况下运行相应程序。我鼓励你__忘掉autoconf、automake等工具，仅使用autoreconf即可__，如下：
本文虽然在讲述Autoconf的初步应用，但依然需要运行两个程序，它们必须按次序运行？（并非如此）。我要在什么时机运行它们？（事实上，每次 'configure.ac'或其依赖文件发生更改之时都要运行这两个程序）。还有没有其他程序也像这样？（当然，automake， libtoolize，gettextize，aclocal……都这般运行）它们的运行次序是否也任意？（是的，本质上皆如此）。实际上，本文与其是讲Autoconf的初步使用，不如说是讲述autoreconf的初步使用：后者囊括了Autoconf中的各类工具，知道在什么情况下运行相应程序。我鼓励你__忘掉autoconf、automake等工具，仅使用autoreconf即可__，如下：[[实例:autoreconf]]
[code2]autoreconf用法
autoreconf用法
[lyanry@lyanry sample]$ ls
configure.ac

4
Zim/Utils/工具链/autoconf---automake/Autotools上手指南.txt
View File

@@ -8,9 +8,7 @@ http://blog.dccmx.com/2011/01/autotools-1/
ccmx 于 2011年 一月 7日 发表 | 最后修改于 2011年 一月 10日
要想弄懂Autotools并使用它，必须先要了解一下M4这个怪物。
那么何为M4呢，M4的名称取自Macro（M后面跟4个字母…）。它和C预处理器里的宏是一个概念（其实，M4和C预处理器都K&R操刀设计的！！），用来处理文本替换。也就是说，M4是bash里的预处理器。
要想弄懂Autotools并使用它，必须先要了解一下M4这个怪物。那么何为M4呢，M4的名称取自Macro（M后面跟4个字母…）。它和C预处理器里的宏是一个概念（其实，M4和C预处理器都K&R操刀设计的！！），用来处理文本替换。也就是说，M4是bash里的预处理器。
取自维基的例子：
divert(-1)

29
Zim/Utils/工具链/autoconf---automake/autoconf软件包.txt
View File

@@ -1,29 +0,0 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2011-12-22T22:26:12+08:00
====== autoconf软件包 ======
Created Thursday 22 December 2011
===== Autoconf的内容 =====
Autoconf 能生成用于自动配置源代码的 shell 脚本(**configure**),该脚本可以生成makefile文件。
安装下列程序: autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate 和 ifnames
===== 简短说明 =====
autoconf是一个产生可以自动配置源代码包，生成shell脚本的工具，以适应各种类UNIX系统的需要。autoconf 产生的配置脚本在运行时独立于autoconf ，因此使用这些脚本的用户不需要安装autoconf。
autoheader能够产生供configure脚本使用的C #define语句模板文件。
autom4te对文件执行 GNU M4。
autoreconf，如果有多个autoconf产生的配置文件，autoreconf可以保存一些工作，它通过重复运行autoconf（以及在合适的地方运行autoheader）以重新产生autoconf配置脚本和配置头模板，这些文件保存在以当前目录为根的目录树中。
autoscan程序可以用来为软件包创建configure.in文件。autoscan在以命令行参数中指定的目录为根（如果未给定参数，则以当前目录为根）的目录树中检查源文件。它为通常的轻便问题搜索源文件，并且为那个包创建一个configure.scan文件，这个文件就是configure.in的前身。
autoupdate程序将一个调用autoconf 宏的旧名称的configure.in文件中的宏更新为新的名称。
ifnames当为一个软件包写configure.in 时，ifnames可以提供一些帮助。它打印包中那些在C预处理器中已经使用了的表示符。如果一个包已经设置成具有某些可移植属性，这个程序能够帮助指出它的配置应该如何检查。它可以用来填补由autoscan产生的configure.in中的隔阂。
===== Autoconf 安装依赖关系 =====
Autoconf 依赖于: Bash, Coreutils, Diffutils, Grep, M4, Make, Perl, Sed.

271
Zim/Utils/工具链/autoconf---automake/实例.txt Normal file
View File

@@ -0,0 +1,271 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2012-12-30T16:56:06+08:00
====== 实例 ======
Created Sunday 30 December 2012
[geekard@geekard demo]$ ls #两文件的代码见附件
demo.c foo.c
[geekard@geekard demo]$ __aclocal__** //aclocal为configure.ac中使用的M4宏提供定义**
aclocal: error: 'configure.ac' is required
[geekard@geekard demo]$ __autoscan__
[geekard@geekard demo]$ ls
autoscan.log __configure.scan__ demo.c foo.c
[geekard@geekard demo]$ mv configure.scan __configure.ac__
[geekard@geekard demo]$ vim configure.ac **//修改configur.ac文件**
[geekard@geekard demo]$ cat configure.ac
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
AC_PREREQ([2.69])
AC_INIT([demo], [0.1], [geekard@qq.com])
AC_CONFIG_SRCDIR([.])
AM_INIT_AUTOMAKE(demo，0.1)
AC_CONFIG_HEADERS([config.h])
# Checks for programs.
AC_PROG_CC
# Checks for libraries.
# Checks for header files.
AC_CHECK_HEADERS([stdlib.h])
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
[geekard@geekard demo]$ __autoheader__ **//在执行该命令前需要先编写configure.ac文件**
[geekard@geekard demo]$ ls
autoscan.log __config.h.in__ configure.ac demo.c foo.c
[geekard@geekard demo]$ cat config.h.in
/* config.h.in. Generated from configure.ac by autoheader. */
/* Define to 1 if you have the <inttypes.h> header file. */
#undef HAVE_INTTYPES_H
/* Define to 1 if you have the <memory.h> header file. */
#undef HAVE_MEMORY_H
/* Define to 1 if you have the <stdint.h> header file. */
#undef HAVE_STDINT_H
/* Define to 1 if you have the <stdlib.h> header file. */
#undef HAVE_STDLIB_H
/* Define to 1 if you have the <strings.h> header file. */
#undef HAVE_STRINGS_H
/* Define to 1 if you have the <string.h> header file. */
#undef HAVE_STRING_H
/* Define to 1 if you have the <sys/stat.h> header file. */
#undef HAVE_SYS_STAT_H
/* Define to 1 if you have the <sys/types.h> header file. */
#undef HAVE_SYS_TYPES_H
/* Define to 1 if you have the <unistd.h> header file. */
#undef HAVE_UNISTD_H
/* Name of package */
#undef PACKAGE
/* Define to the address where bug reports for this package should be sent. */
#undef PACKAGE_BUGREPORT
/* Define to the full name of this package. */
#undef PACKAGE_NAME
/* Define to the full name and version of this package. */
#undef PACKAGE_STRING
/* Define to the one symbol short name of this package. */
#undef PACKAGE_TARNAME
/* Define to the home page for this package. */
#undef PACKAGE_URL
/* Define to the version of this package. */
#undef PACKAGE_VERSION
/* Define to 1 if you have the ANSI C header files. */
#undef STDC_HEADERS
/* Version number of package */
#undef VERSION
[geekard@geekard demo]$ cat __Makefile.am__
bin_PROGRAMS = demo //生成的可执行程序名称
demo_SOURCES = demo.c foo.c //可执行程序依赖的源文件
[geekard@geekard demo]$ __aclocal //在执行automake和autoconf前需要先执行aclocal，该命令为configure.ac文件中使用的M4宏提供定义。__
[geekard@geekard demo]$ ls
__aclocal.m4 autom4te.cache__ autoscan.log configure.ac demo.c foo.c Makefile.am
[geekard@geekard demo]$ __automake //在执行automake前必须定义configure.ac和Makefile.am文件__
configure.ac:7: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see:
configure.ac:7: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_INIT_AUTOMAKE-invocation
configure.ac:7: error: required file './install-sh' not found
configure.ac:7: 'automake --add-missing' can install 'install-sh'
configure.ac:7: error: required file './missing' not found
configure.ac:7: 'automake --add-missing' can install 'missing'
Makefile.am: error: required file './INSTALL' not found
Makefile.am: 'automake --add-missing' can install 'INSTALL'
Makefile.am: error: required file './NEWS' not found
Makefile.am: error: required file './README' not found
Makefile.am: error: required file './AUTHORS' not found
Makefile.am: error: required file './ChangeLog' not found
Makefile.am: error: required file './COPYING' not found
Makefile.am: 'automake --add-missing' can install 'COPYING'
Makefile.am: error: required file './depcomp' not found
Makefile.am: 'automake --add-missing' can install 'depcomp'
[geekard@geekard demo]$ __automake --add-missing__
configure.ac:7: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see:
configure.ac:7: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_INIT_AUTOMAKE-invocation
configure.ac:7: installing './install-sh'
configure.ac:7: installing './missing'
Makefile.am: installing './INSTALL'
Makefile.am: error: required file './NEWS' not found
Makefile.am: error: required file './README' not found
Makefile.am: error: required file './AUTHORS' not found
Makefile.am: error: required file './ChangeLog' not found
Makefile.am: installing './COPYING' using GNU General Public License v3 file
Makefile.am: Consider adding the COPYING file to the version control system
Makefile.am: for your code, to avoid questions about which license your project uses
Makefile.am: installing './depcomp'
[geekard@geekard demo]$ __touch NEWS README AUTHORS ChangeLog__
[geekard@geekard demo]$ **automake**
configure.ac:7: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see:
configure.ac:7: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_INIT_AUTOMAKE-invocation
[geekard@geekard demo]$ ls
aclocal.m4 autom4te.cache ChangeLog config.h.in COPYING depcomp INSTALL Makefile.am missing README
AUTHORS autoscan.log ChangLog configure.ac demo.c foo.c install-sh __Makefile.in__ NEWS
[geekard@geekard demo]$ __autoconf__ //**最后一步执行autoconf命令，如果先于automake执行则会提示**
**configure.ac:7: error: possibly undefined macro: AM_INIT_AUTOMAKE**
** If this token and others are legitimate, please use m4_pattern_allow.**
** See the Autoconf documentation.**
[geekard@geekard demo]$ ls
aclocal.m4 autom4te.cache ChangeLog config.h.in configure.ac demo.c foo.c install-sh Makefile.in NEWS
AUTHORS autoscan.log ChangLog __configure__ COPYING depcomp INSTALL Makefile.am missing README
[geekard@geekard demo]$ **./configure**
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
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 ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking that generated files are newer than configure... done
configure: creating __./config.status__
**config.status:** creating __Makefile__
config.status: creating __config.h__
config.status: executing __depfiles__ commands
[geekard@geekard demo]$ **make**
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/geekard/Code/elf/demo/missing --run aclocal-1.12
cd . && /bin/sh /home/geekard/Code/elf/demo/missing --run automake-1.12 --gnu
configure.ac:7: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see:
configure.ac:7: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_INIT_AUTOMAKE-invocation
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/geekard/Code/elf/demo/missing --run autoconf
**/bin/sh ./config.status --recheck**
running CONFIG_SHELL=/bin/sh /bin/sh ./configure --no-create --no-recursion
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
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 ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking that generated files are newer than configure... done
configure: creating ./config.status
/bin/sh ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/geekard/Code/elf/demo/missing --run autoheader)
rm -f stamp-h1
touch config.h.in
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
**make all-am**
make[1]: Entering directory `/home/geekard/Code/elf/demo'
gcc -DHAVE_CONFIG_H -I. -g -O2 -MT demo.o __-MD -MP -MF .deps/demo.Tpo__ -c -o demo.o demo.c
demo.c: In function ‘greeting’:
demo.c:24:3: warning: initialization from incompatible pointer type [enabled by default]
demo.c:24:3: warning: (near initialization for ‘pp’) [enabled by default]
demo.c:24:3: warning: excess elements in scalar initializer [enabled by default]
demo.c:24:3: warning: (near initialization for ‘pp’) [enabled by default]
demo.c:24:3: warning: excess elements in scalar initializer [enabled by default]
demo.c:24:3: warning: (near initialization for ‘pp’) [enabled by default]
demo.c:24:3: warning: excess elements in scalar initializer [enabled by default]
demo.c:24:3: warning: (near initialization for ‘pp’) [enabled by default]
mv -f .deps/demo.Tpo .deps/demo.Po
gcc -DHAVE_CONFIG_H -I. -g -O2 **-MT foo.o -MD -MP -MF .deps/foo.Tpo** -c -o foo.o foo.c
mv -f .deps/foo.Tpo .deps/foo.Po
gcc -g -O2 -o demo demo.o foo.o
make[1]: Leaving directory `/home/geekard/Code/elf/demo'
**#上面的-MD -MP -MF ./deps/demo.Tpo定义了demo程序的依赖文件。**
[geekard@geekard demo]$ ls
aclocal.m4 autoscan.log config.h config.status COPYING demo.o foo.o Makefile missing stamp-h1
AUTHORS ChangeLog config.h.in configure __demo__ depcomp INSTALL Makefile.am NEWS
autom4te.cache ChangLog config.log configure.ac demo.c foo.c install-sh Makefile.in README
[geekard@geekard demo]$ ./demo
In main:
The globalVarStatic is:3
In greeting:
Hello, geekard:
Yourt age is:23.
Yourt friends are:
Tom
John
Pi
Goodbye from greeting.
[geekard@geekard demo]$

53
Zim/Utils/工具链/autoconf---automake/实例/autoreconf.txt Normal file
View File

@@ -0,0 +1,53 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2012-12-30T17:40:36+08:00
====== autoreconf ======
Created Sunday 30 December 2012
利用autoreconf工具，会自动生成相关的文件。
[geekard@geekard demo]$ ls
**configure.ac demo.c foo.c Makefile.am**
[geekard@geekard demo]$ **autoreconf**
configure.ac:7: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see:
configure.ac:7: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_INIT_AUTOMAKE-invocation
configure.ac:7: error: required file './install-sh' not found
configure.ac:7: 'automake --add-missing' can install 'install-sh'
configure.ac:7: error: required file './missing' not found
configure.ac:7: 'automake --add-missing' can install 'missing'
Makefile.am: error: required file './INSTALL' not found
Makefile.am: 'automake --add-missing' can install 'INSTALL'
Makefile.am: error: required file './NEWS' not found
Makefile.am: error: required file './README' not found
Makefile.am: error: required file './AUTHORS' not found
Makefile.am: error: required file './ChangeLog' not found
Makefile.am: error: required file './COPYING' not found
Makefile.am: 'automake --add-missing' can install 'COPYING'
Makefile.am: error: required file './depcomp' not found
Makefile.am: 'automake --add-missing' can install 'depcomp'
autoreconf: **automake** failed with exit status: 1
**[geekard@geekard demo]$ ls //可见自动调用了aclocal命令**
aclocal.m4 autom4te.cache config.h.in configure configure.ac demo.c foo.c Makefile.am
[geekard@geekard demo]$ __automake --add-missing__
configure.ac:7: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see:
configure.ac:7: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_INIT_AUTOMAKE-invocation
configure.ac:7: installing './install-sh'
configure.ac:7: installing './missing'
Makefile.am: installing './INSTALL'
Makefile.am: error: required file './NEWS' not found
Makefile.am: error: required file './README' not found
Makefile.am: error: required file './AUTHORS' not found
Makefile.am: error: required file './ChangeLog' not found
Makefile.am: installing './COPYING' using GNU General Public License v3 file
Makefile.am: Consider adding the COPYING file to the version control system
Makefile.am: for your code, to avoid questions about which license your project uses
Makefile.am: installing './depcomp'
[geekard@geekard demo]$ __touch NEWS README AUTHORS ChangeLog__
[geekard@geekard demo]$ __autoreconf__
configure.ac:7: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see:
configure.ac:7: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_INIT_AUTOMAKE-invocation
[geekard@geekard demo]$ ls **//可见自动调用了automake和autoconf**
aclocal.m4 autom4te.cache config.h.in configure.ac demo.c foo.c install-sh Makefile.in NEWS
AUTHORS ChangeLog __configure__ COPYING depcomp INSTALL Makefile.am missing README
[geekard@geekard demo]$

67
Zim/Utils/工具链/autoconf---automake/实例/demo.c.txt Normal file
View File

@@ -0,0 +1,67 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2012-12-30T17:09:44+08:00
====== demo.c ======
Created Sunday 30 December 2012
#include <stdio.h>
#include <stdlib.h>
//已初始化全局变量，保存在.data section中。
int globalVar = 1;
//未初始化全局变量，当生成可重定位obj文件时，位于COMMON section中。
int globalVarUninit;
//对于static类型的变量和函数的引用，使用GOTOFF类型重定位。
static int globalVarStatic = 3;
extern int externVar;
//对于外部函数的调用，使用PLT形式重定位。
extern int add(int, int);
void greeting(char *name, int age, char** friends)
{
int a = 23;
char *nm = "zhangjun";
//ap为数组名称，本身不占用内存单元
char *ap[] = {"Tom", "John", "Pi", NULL};
//pp为指针变量，指向一块保存有三个字符指针的内存单元(位于greeting的栈中)
char **pp = {"Tom", "John", "Pi", NULL};
if (name == NULL)
name = nm;
if (age == 0)
age = a;
if (friends == NULL)
friends = pp;
printf("In greeting:\n");
printf("\tHello, %s:\n", name);
printf("\tYourt age is:%d.\n", age);
printf("\tYourt friends are:\n");
while (*friends != NULL) {
printf("\t\t%s\n", *friends);
friends += 1;
}
printf("Goodbye from greeting.\n");
}
int main(int argc, char *argv[])
{
int autoVar = globalVar;
static int staticVar = 2;
int i = externVar;
char *name = "geekard";
int age = 23;
//friends为数组名称.
char *friends[] = {"Tom", "John", "Pi", NULL};
printf("In main:\n");
printf("\tThe globalVarStatic is:%d\n",globalVarStatic);
greeting(name, age, friends);
add(2, 3);
}

14
Zim/Utils/工具链/autoconf---automake/实例/foo.c.txt Normal file
View File

@@ -0,0 +1,14 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2012-12-30T17:09:48+08:00
====== foo.c ======
Created Sunday 30 December 2012
int externVar = 1;
int static staticVarStatic = 2;
int add(int a, int b)
{
return a + b;
}