在emacs里可以用etags命令生成emacs专用的tags文件，有了此文件之后便可以使用一些emacs tags的命令，比如对于编辑C/C++程序的人员可以方便的定位一个函数的定义，或者对函数名进行自动补齐：

我在使用上述命令时未能成功，但以下命令可以

或

上述命令可以在当前目录查找所有的.h和.cpp文件并把它们的摘要提取出来做成TAGS文件，具体的etags的用法可以看一下etags的manual。

创建好tag表后，告知emacs。
M-x visit-tags-table

在.emacs中加入这样的语句：

这样emacs就会自动读取这个tags文件的内容。

几个重要的命令。

• M-. 查找一个tag，比如函数定义类型定义等。
• C-u M-. 查找下一个tag的位置
• M-* 回到上一次运行M-.前的光标位置。
• M-TAB 自动补齐函数名。

Emacs的日常生活

robinh

October 15, 2003

Chapter 1

前言

有很多很多现成的文章介绍 Emacs 的。大致有那么两种：一种介绍说， Emacs 是一个无比强大的文本编辑器，但是不管谁用了一下都会觉得，这个文本编辑器真是难用了，所有的命令都是组合出来的怪物。甚至 Emacs 自己的帮助文档里面也说，用 Emacs 多的了用户会希望终端的输入设备加上两个脚踏板）；另一种介绍说 Emacs 是一个无比强大的 IDE ，但是对于象我们这样见过 Visual Studio 之类市面的新新人类来说，这“无比强大”大致上和“刀枪不入”是一个档次的广告。

Emacs 在我的概念中到底是个什么样的呢？它是一个环境。 Emacs 可以什么都是，也可以什么都不是，因为环境本身不创造什么。 Emacs 的强大是因为前人已经在这个环境中作了很多尝试，所以你不用从头发明轮子。 Emacs的强大是因为它能够将各种软件统一到同样一个界面底下来，你就可以以相仿的方式，操作各种其实并不相仿的程序。 Emacs的最强大之处在于它本身并不强迫你接受什么，不就是个Lisp程序嘛，不满意的地方你可以改，哪怕你其实不怎么懂Lisp。

以下的文字，说起来有一些混乱，因为我常常引用一些在介绍的同时并没有给出说明的概念。这又有什么关系呢？Lisp不是C++，它并不要求你在真正开始用这个概念之前就已经掌握了它的实际含义。而你真正想到用这个概念的时候，你肯定已经掌握了它。

Chapter 2

Emacs基础

Emacs最好的入门教材，不是 Emacs 自己带的 toturial 。实际上就是这个 tutorial 给好多人非常恶劣的印象， Emacs 是一个操作复杂的变态编辑器。人性化一点的 Emacs 教材，大致有这一些：

1. Sams Teach Yourself Emacs in 24 Hours ，可以从这里下载。

2. 《如何使用Emacs编辑器》，这是已经出了中文版的了，不过不值得推荐，因为是在是太贵太陈旧了。

关于 Elisp 的入门教材是《GNU Emacs Lisp编程入门》，这本书实际上就是elisp introduction这个info文件的翻译，翻译质量不错，而且纸版的书看起来确实比较舒服。Emacs自带的有一个Elisp手册，真的就只能当手册用，全无可读性可言。

使用Emacs的技巧在http://www.emacswiki.org 上有很多，常去翻翻很长见识。

因为 Emacs 是一个单线程的应用程序，所以有可能一个操作占用了太长的时间，让使用者觉得很不爽。实际上很多 Emacs 的使用者，同时都起若干个 Emacs 进程，其中一个专门做一些耗时的操作，比如收信。如果你只愿意起一个进程，并且实在不耐烦等下去，C-g可以直接将进行到一半的操作停止下来。 Emacs 里面所有作到一半的事情，只要 Emacs 没有崩溃，就可以用C-g停止掉。

Emacs 对自己的描述非常完备，C-h可以带你进入 Emacs 的文档世界。常见比如：

1. C-h k可以告诉你按下某一键的时候到底有什么函数被调用；

2. C-h m可以告诉你当前的模式到底有什么特别之处；

3. C-h f可以告诉某一个函数到底有一些什么作用。

习惯这一些你会发现， Emacs 里面查帮助其实比 MSDN 还要方便。

Chapter 3

如何安装Emacs

是的是的，我知道你会有自己安装 Emacs 的方法。你要是 RedHat 的用户，你肯定是下载 rpm 包回来装；你要是用的 debian ，你多半是apt-get；你要是用 gentoo ，你就 emerge 一把；你要是用 Windows ，你会上网去找安装文件；你要是用BSD的，你多半就去make port了；再大不了你会用 cvs 把最新的 Emacs 代码拉回来，然后在自己的机器上重新编译。

但是，这些方法只能帮助你安装 Emacs 本身。 Emacs 绝不仅仅是一个大大的tar包，或者是一个大大的安装文件能够包括的。你下回来的 Emacs ，相当于是一个Java的虚拟机，你真正面对的，是互联网上elisp资源的汪洋大海。所以我们关心的，其实是怎么安装这些零零碎碎从网络上 download 回来的资源。

Emacs 的软件，一般都是一个压缩包。因为 Emacs 没有象 Python 那样完善的安装机制，所以这个安装过程一般都要看着说明文档自己一步一步来。作为一个 Emacs 平台下的软件，它总得有这样几个组成部分：

1. 有部分是用 elisp 写的，不然的话没法给 Emacs 用；

2. 可能有部分是平台相关的代码，一般都是些可执行的二进制文件或者脚本。

3. 可能还有一些info格式的相关文档。

可执行的二进制文件只要放在$PATH环境变量所包含的目录下，就可以被调用了，这和一般的程序并无区别。

而elisp写就的 Emacs 软件则稍微有一些不同。你如果想在 Emacs 里面调用一个函数，你得先有这个函数的定义；为了有这个函数的定义，你必须显式地将拥有函数定义的elisp文件载入 Emacs 环境；为了将 elisp文件正确载入 Emacs ， Emacs 会在load-path这个变量所包含的所有目录下寻找同名文件。所以，说到底，安装elisp软件的过程，就是将它拷贝到某一个 load-path目录下，并且在.emacs文件显式载入这个文件的过程。

一般FAQ上给出的建议，是将自己下回来的elisp包，放在某一个名叫 site-lisp的目录之中。这是个不错的建议，不过问题在于大多数Linux的发布版厂商，习惯把他们自己维护的一些elisp资源包也扔到site-lisp这个目录里面去，这造成的结果就是，有一天你突然想备份自己的Emacs资源的时候，你突然发现分不清那些是自己想要的，哪些是不小心让系统装上去的垃圾。

所以，建议你还是在自己的$HOME目录底下建一个专门给Emacs用的目录，名字嘛，可以就叫emacs。$HOME/emacs这个目录里面至少可以分出两个子目录来，一个是config，我们从此就可以把所有Emacs配置的内容放到这个目录底下，并且分门别类起来；另一个叫package，里面就可以堆放各种从网络上下载回来的elisp资源。

所有扔到site-lisp目录里面的elisp文件夹，在emacs起动的时候都会自动被加入load-path列表，这是site-lisp/subdirs.el的功劳。我们的package/subdirs.el也要有这个功能。

(defun my-add-subdirs-to-load-path (dir)
 (let ((default-directory (concat dir "/")))
  (setq load-path (cons dir load-path))
  (normal-top-level-add-subdirs-to-load-path)))

(my-add-subdirs-to-load-path "~/emacs/packages")

然后在.emacs文件中显式载入这个文件。

(load "~/emacs/packages/subdirs")

Chapter 4

让Emacs变得轻快
Emacs最为人诟病的一点，就是它起动太慢。也难怪，光看可执行文件的尺寸，一个 emacs 差不多就是一个 vim 的5倍了，起动起来能快得了嘛。更何况大多数人都把以前用 vi 的习惯照搬到用 emacs 的情况下面来，每次要编辑一个文件的时候，就起动一个新的 Emacs 进程。您要是也习惯这种 Vi 风格，那您用 Emacs 可就得慢慢等着啦。因为 Emacs 的风格，是所有事情都在 Emacs  里面完成，包括浏览目录，打开文件。当然， Emacs 也不是完全排斥 Vi 风格，至少  Unix 环境下的 Emacs 就自带了一个叫 emacsclient 的程序，是个完全轻量级的东东，让你可以象起动 vi 那样轻松起动 emacs 。还有一个独立的程序，叫 gnuserv 的，更尽一步，支持 Windows 平台下的 Emacs ，而且功能也更多一些。反正是要用，干脆就用个好的吧。
Unix下的gnuserv可以从  http://www-uk.hpl.hp.com/people/ange/gnuserv/ 下载， Windows下的gnuserv建议在  http://www.wyrdrune.com/gnuserv.html 里面找。 gnuserv的安装并不复杂，无非是将几个可执行文件放到%PATH%变量提及的地方，然后将 gnuserv.el 放到 load-path 所包含的目录中去，最后在配置文件中加入两句配置：
(require 'gnuserv)
(gnuserv-start)
这是Emacs安装插件的标准做法。以下还有一些代码，是从David Vanderschel的帖子上抄来的，偶一般将其中的dv-close-client-frame绑定到C-上，估计也会有人喜欢绑定到C-F4上。
(defvar dv-initial-frame 
  (car (frame-list)) 
  "Holds initial frame.")

(defun dv-focus-frame (frame) 
  "pop to top and give focus"
  (make-frame-visible frame)
  (raise-frame frame)
  (select-frame frame)
  (w32-focus-frame frame))

(defvar dv-mail-frames ()
  "Frames created by dv-do-mailto")

(defun dv-focus-initial-frame () 
  "Make the initial frame visible"
  (dv-focus-frame dv-initial-frame))

(defun dv-do-mailto (arg) 
  "For handling mailto URLs via gnudoit"
  (dv-focus-frame (make-frame))
  (message-mail (substring arg 7))
  (delete-other-windows)
  (setq dv-mail-frames 
    (cons (selected-frame) dv-mail-frames)))

(defun dv-close-client-frame () 
  "Close frame, kill client buffer."
  (interactive)
  (if (or (not (member (selected-frame) dv-mail-frames))
          (and (> (length (buffer-name)) 4)
               (equal (substring (buffer-name) 0 5) 
                      "*mail")
               (not (buffer-modified-p))))
      (kill-buffer (current-buffer)))
  (setq dv-mail-frames 
        (delete (selected-frame) dv-mail-frames))
  (if (equal (selected-frame) dv-initial-frame)
      (iconify-frame)
    (delete-frame)))

(defun dv-paste-to-temp () 
  "Load clipboard in a temp buffer"
  (dv-focus-frame (make-frame))
  (switch-to-buffer (generate-new-buffer "temp"))
  (clipboard-yank))
再如果，你和我一样是个win32底下的懒人，那么估计你还需要这个。
(defun w32-restore-frame (&optional arg)
    "Restore a minimized frame"
     (interactive)
     (w32-send-sys-command 61728 arg))
(defun w32-maximize-frame (&optional arg)
    "Maximize the current frame"
     (interactive)
     (w32-send-sys-command 61488 arg))
(w32-maximize-frame)
(add-hook 'after-make-frame-functions 'w32-maximize-frame)
这可以使得每一个新打开的frame都自动最大化。
Chapter 5

安排自己的时间
如果你已经是一个善于管理自己时间的人，那么Emacs的这些功能可能就全都没有必要了。不过，如果你和我一样在这个方面拎不清，Emacs 就显得很帮忙了。
以下的内容加入到.emacs文件中，会有不少帮助。
(setq display-time-24hr-format t)
(setq display-time-day-and-date t)
(display-time)

(setq todo-file-do "~/emacs/todo/do")
(setq todo-file-done "~/emacs/todo/done")
(setq todo-file-top "~/emacs/todo/top")

(setq diary-file "~/emacs/diary")
(setq diary-mail-addr "you@your.email.address")
(add-hook 'diary-hook 'appt-make-list)
将所有emacs里面用到的文件都放到~/emacs目录中去，偶觉得是个好习惯。
对于大多数预期要做的事情，使用todo模式是最方便的，偶的习惯是访问do文件的时候，作一个bookmark(使用M-x bookmark-set命令)，这样以后访问起来就很方便了。bookmark是Emacs很有用的功能，偶一般就把 list-bookmark绑定到F12上去，随手就能钩着。想起什么事情的时候，随手就切到todo那边去，找一个catalog，用I命令插入一个新的entry；做完了一件事情，随手切到todo那边去，用d或者f就能把entry去掉。每个星期结束的时候，看看done文件，就会有“日子过得好充实阿”酱紫的感叹。
也有的事情没有那么重要，写不成todo的。这个时候就用 appointment 。用 (setq appt-issue-message t)确认打开了约会提醒功能，然后用appt-add命令就可以加入新的约会提醒。比如在电话里和mm吵架了，挂了电话以后，在 Emacs 里面使用M-x appt-add命令加一条记录，估计一下半个小时以后，给mm打个电话赔礼道歉。半个小时以后， Emacs 就会跳出一个小框来提醒说，该打电话了。当然，如果半个小时之内，mm主动打电话回来修好，那就用 M-x appt-delete命令删掉提醒好了。
对于那些周期性比较长的事情，可以用diary。我刚开始用diary的时候，以为diary是用来帮助写日记的，所以试了一下觉得好难用阿。仔细看看，发现diary其实是用来做行程管理的。
单独用 diary 没什么意思的，所以info里面 diary 也是和 calendar 放在一起的。偶把 calendar 绑定到F8上 (global-set-key [(control f8)] 'calendar)。启动calendar会出现一个小窗口，显示当前日历。calendar 模式底下命令很多，但是常用的就那么几个，.命令可以跳回当今天，o命令可以跳到某一个月。g系列命令表示goto，可以跳到指定的某一天，g d 是跳到某年某月某日，g c是跳到某年某星期的星期几，g C可以跳到阴历的某一天。p系列命令表示print，可以按照某格式显示当前日期，比如p C就可以显示当前的阴历日期。偶们现在比较关心的是i系列命令，i d是加入当前这一天的行程安排，d表示的是day，显然依此类推还有m，y，w。
比如mm打个电话来说，星期天要陪她去颐和园。用Emacs记一下吧，免得忘了。打开calendar，跳到星期天上面，i d，陪mm去颐和园。又比如老板说，以后每个星期一都给我交一份报告上来，打开calendar，跳到某个星期一上面，i w，交报告给老板。还有一个常用的，比如mm生日是 9/29，打开calendar，跳到9/29，i a，a代表anniversary，mm生日。养成用diary的习惯以后，经常性的打开calendar，跳到某一天，按一下d，就可以看那一天有哪些安排了。相比之下，h命令对偶来说就很垃圾。
diary文件里面可以写一些更详细的内容，比如直接把一个约会提醒写到diary里面，偶觉得这个不是很方便。diary文件不过是一个纯文本，有什么不满意的话，可以直接去修改，记得打开diary文件的时候，切回基本模式，不然很多东西是看不到啦。
有的更完整一些的模式，比如plan模式，需要额外从网上下载，可以将作出的plan转换成pp的个人主页。不过我是不会用的啦。
Chapter 6

用Emacs写东西
虽然写程序也叫做写东西，可是我们现在要讨论的不是它。我们大部分的时间里写的，是拿到bbs上灌的，是留到以后查的。Emacs有一些不错的特点，可以方便上面说的这些事情。
大部分的时间里，我们要写的文章写成TEX挺困难，因为不是那么有条理；但是直接当纯文本处理，似乎又太没有条理。这种时候，用Emacs 的outline-mode就很合适。outline模式最大的好处是简单：只要在行首放上几个星号“*”，就可以表达文章的条理关系。比如，看《爱丽丝漫游奇境》是做一点摘录，先打开一个新文件C-x C-f；然后打开outline模式M-x outline-mode；再然后呢，第一章的内容，先来一个*吧，写上第一章的题目；第一章的写完了，C-c C-c就可以把前面写的内容都折起来，只留下一个标题，看起来很是清爽。过一段时间想起来翻查的时候，C-x C-f打开文件，还是进入outline-mode，C-c C-o就把所有内容都折起来了，只留下标题，文件里面到底有些什么内容，也都一目了然了。
这样做有一个缺点，就是很容易把所有内容都堆到同一个文件里面，眼看着文件越来越大，很容易就要上兆了。不过Emacs是支持直接编辑压缩文件的，用auto-compression-mode就可以。
另外一个经常让人头疼的问题，就是文章的排版。特别是要拿到bbs 上贴的文章，bbs虽然号称支持自动换行，但是那也只是个聊胜于无的东西，要想给人看，还是得手动换行才行。Emacs可以把一句长长的话自动分成若干行，而且这个效果一般都很让人满意。只要把point移动到需要重新整理的段落之中，M-q，就可以完成排版的工作。如果这样还嫌麻烦，那么做成宏也是个不错的注意。如果文章是自己在写，那么打开 auto-fill-mode，是个不错的注意。auto-fill模式可以在写的同时，帮你做换行的工作。
如果写的东西大部分是英文的，还可以考虑打开flyspell-mode。不过这个东西需要后面有ispell支持。win32底下有一个native的ispell v4，不过用起来挺不爽的：v4是一个已经放弃的版本，这是一；和现有的其他模式搭配也不愉快，这是二。v3里面现成的win32版本有两个，建议装一个 cygwin。 另外也有一个win32 native的，可以从  http://www.fsci.fuk.kindai.ac.jp/ kakuto/win32-ptex/web2c75-e.html  找到，日本人做的，我也没有试过。打开flyspell-mode之后，写东西的过程当中，ispell认为写错了的单词，就会自动高亮，很是显眼。 M-$可以让Emacs提示你写错的单词到底应该怎么拼。win32的Emacs 21还没支持 tooltip，所以有些看起来很炫的功能不能用。不过偶觉得就上面说的几种模式，一般过日子也就足够了。
尝试过 wiki 的同学，也可以试用一下 Emacs 下的 wiki 模式，不过偶以为 wiki 模式不适合给说中文的人用。
Chapter 7

管理自己的地盘
我习惯没事情干的时候，就逛自己的硬盘。相信很多人有和我类似的毛病，上网的时候看到好的文章就存下来，时间一长，硬盘的各个角落里面就堆满了各种各样的html，txt文件。只能常常抽空遍历一下自己的目录，看看又多了一些什么东西。这件事情用cmd.exe可以做，用资源管理器也能做，不行话还有wincmd，totalcmd之类的软件。当然用惯命令行的还是觉得用sh.exe最好。
Emacs既然是个八卦，就会八卦到底，它至少提供了另外两种选择，  eshell 和 dired 。
 eshell 看起来就很象一个 shell 了，不过拿它就做一个 shell 那也太委屈它了， eshell 带的 pcomplete 自动补全功能比 bash 之类的shell，还是有差距的。但是eshell的特长在于，可以直接使用 emacs lisp 的函数做命令。比如偶比较喜欢的 (defalias 'vi 'find-file)  （前提是系统里面没有vi的可执行文件），这样在eshell里面，vi一个文件，就会弹出一个新的 emacs buffer 。充分发挥想象力吧。唯一要注意的是， eshell 里面不能用C-c取消一个输入了一半的命令，我的做法一般是C-a C-k，其实也不太麻烦的。
说到自动补全，不知道什么时候开始，突然发现几乎所有的shell，所有的编辑器都支持用tab来做自动补全了。Emacs当然也可以这样设定，不过有的时候，我们还是会怀念用tab来indent，不是吗？用这样一个函数吧：
(defun my-indent-or-complete ()
  "如果在词尾，那就hippie-expand，否则就indent"
  (interactive)
  (if (looking-at ">")
      (hippie-expand nil)
    (indent-for-tab-command)
    ))
(global-set-key [(tab)] 'my-indent-or-complete)
hippie-expand虽然已经很不错了，不过我们可以让它更强一点的， 
(autoload 'senator-try-expand-semantic "senator")
然后再 
(setq hippie-expand-try-functions-list
      '(
        senator-try-expand-semantic
        try-expand-dabbrev
        ;;........
        ))
当然前提是要装一个semantic，这个以后再说。
Dired看起来就更象一个wincmd。常用的命令也就是v（查看），e （编辑），d（标记删除），x（执行删除）。以前一度，我喜欢再dired里面做el文件的byte compile，只要在需要compile的文件上面按B就可以了，不过现在发现，那样还不如用这样一行命令合算： 
(byte-recompile-directory "/path/to/somewhere" 0 t)
自动重新编译一个目录下面所有的el文件。Emacs和python不一样， elc 和el执行速度会差的很多，mule-ucs就是一个典型，编译之前启动一次要半分钟，编译之后启动就是一眨眼的事情了。当然编译也是一个很费时的事情。真是的。
Chapter 8

用Emacs写程序
Emacs号称是一个强大的IDE，可是往往被人误解。甚至常常有人以为，让VS.net的热键设置和Emacs一样，VS.net就算可以模仿Emacs了，这个基本上是比天只小一点点的笑话。
还是从写还是吧。
基本上那些常见的编程语言，Emacs都有支持。我们现在说的支持，基本上就限于有一种对应于这种语言的major mode。最常见的就是cc-mode了，甚至还专门拿出来，在sourceforge上做了一个项目的说。cc-mode可以不错的支持各种语法上有些类似c的语言，甚至于idl。
不过， cc-mode 不支持c Sharp 。 google 上能搜到一些给 Emacs 用的 c sharp major mode ，我觉得  http://davh.dk/script上的那个不错；别的大都需要对  Emacs 自带的 cc-mode 做替换，让人觉得很不爽。前面提到的那个，在 Emacs 21.3.xx上可能需要作一点小的修改，大概621行左右的位置，  (c-common-init)改成(c-common-init 'c-mode) ，大致如此。
Python mode需要到http://www.python.org上去下载。
有了这些以后，基本上不愁写程序的时候的语法加亮的问题了。（其实本来也没什么好愁的，毕竟这是最基本的要求）。
有人偏爱ue那样，把当前行高亮的样子，那就先打开M-x hl-line-mode。
有人看到 ThisIsASimpleVarInJava 就觉得郁闷，那就打开 M-x glasses-mode 。
关于补全，上次提到过，hippie-expand加上semantic是现在最好的选择了。dabbrev-expand完全不懂语义的，常常给扩展出一些莫名其妙的内容来，semantic就不一样了。它至少是懂的语义的，expand的结果看起来就合理的多，有的时候甚至能够认出某一个变量的类型来，让我激动了老半天，当然，只是有时候阿。semantic可以从 http://sf.net/projects/cedet上下载。别的还有一些东西，比如jde或者ecb都是建立在semantic的基础上的，写java的话，也可以用jde，比elipse之类当然是要轻的多了。ecb偶没用过。 http://www.xref-tech.com上的xref 支持更出色，不过那就不是自由软件的范畴了。
关于宏，c语言最麻烦的可能是宏了。常常是面对嵌套了若干层的宏，看不出一个所以然来。 这个时候，可以直接用C-c C-e，对已经选定的区域做预处理，预处理的结果会显是在另外的buffer里面。这项工作缺省使用cpp来做，不过只要编译器支持从标注输入读入代码，好像都可以正常工作。另外有一些简单的宏，比如用来做平台选择的，直接用 hide-ifdef-mode就可以摆平，都免去了调用预处理器的麻烦。
关于代码隐藏，其实偶一般只用一个C-c @ C-c，hs-troggle-hiding。基本上能够满足要求了。 不过用之前记得先打开M-x hs-minor-mode。
关于文件，有一个很方便的命令。取个名字叫my-find-related-file。这个命令可以打开当前.c文件中所有include了的文件。
(defun my-find-related-file ()
  "Find all related files in this buffer"
  (interactive)
  (save-excursion
    (let ((my-buffer (current-buffer)))
    (goto-char (point-min))
    (while (search-forward-regexp " *# *include" (point-max) t)
      (progn 
        (ff-find-other-file) 
        (switch-to-buffer my-buffer) 
      )))))
还有就是注意，ff-search-directories早一点设定，用过一次ff函数以后，再setq就晚了。 ;-) 以上。
关于查看帮助，有的选的有info和woman。woman可以用来看man能查到的帮助。一般可以把下面这点代码绑定到f1上。 
(global-set-key [(f1)] (lambda() 
                 (interactive) 
                 (let ((woman-topic-at-point t))
                 (woman))))
也可以用C-h C-i在info里面查看函数。这些都很简单了。如果你还不满足，那就直接google吧，可以考虑利用browser-url。 ;-)
关于自动排版。自动排版算是一个比较重要的功能，特别是对于那些版式和程序结构没有影响的语言，让代码的排版比较迎合个人的喜好，这个不过分吧。对于整个文件做重排，一般要C-x h选定整个buffer，然后 C-M-重新排版。 这个一般比较耗时间，如果代码文件确实很长的话。折中的做法是在一个代码端开始的地方，就是{处，用C-c C-q，酱紫可以排版一个代码段。排版的风格可以用c-set-style来设定，偶一般用 stroustrup，表达偶对他的仰慕。如果对于具体的某一个设置不满意，可以在不满意的地方用C-c C-s看一下，这里缩进的设置是取决于什么的；然后可以用C-c C-o修改之。
关于移动。程序代码里面移动来移动去，也是一个问题。最直接的办法当然是用鼠标了。不过各种模式里面一般也都会对常见的移动键位做修订，可以自己试一试，找出比较常用的键来。几乎所有的模式都会支持以函数定义为单位移动，这个一般都很好用。
关于tag，Emacs附带的etags可以用来生成TAGS文件。在某个源文件中 M-.，Emacs会询问访问哪一个TAGS文件，这个基本上和vi差不多。更强悍一点的是ebrowser，生成一个BROWSER文件，只要find-file这个文件，就会进入ebrowser的模式，有一点类似于cscope。speedbar在这个时候可以来帮忙，试试看就知道了，不过好不好使就完全是一个见仁见智的问题。上次说到的ecb（sf.net/projects/ecb），也着眼于解决这一类问题，有兴趣试试？
关于grep，Emacs自己没有grep功能（ft）。不过好在grep这个东西不管哪个平台都有，win32底下叫做findstr（ft again）。可以尝试一下 grep，grep-find。 前者是直接把参数传递给grep的，后者是把参数传递给find + grep，两者都会在当前buffer对应文件所在的目录下面进行。反正和直接在console下面玩没什么两样的。
关于diff，ediff模式很不错的。比较爽的做法是在eshell里面用。 ediff a.c.orig a.c。 特别注意的是，ediff的session控制区是一个小窗口，那个小窗口关掉，就算是退出ediff了哦。ediff可以忽略空格的。对应的epatch较之直接用patch的优点就在于，patch完了以后就直接进入 ediff模式，什么地方做了改动一目了然。
关于注释，虽然最简单的做法是用C-c C-c注释掉整块已经选定的区域，但是这种做法不一定是最好的。如果是想将暂时不需要的代码抹掉，还是用#if 0/#endif比较合适，因为我一般用flyspell-prog-mode来检查注释里面有没有单词拼写错误。如果你不想看到代码里面被指出很多拼写错误来，那还是不要滥用C-c C-c的好。
 xref 是一个用起来挺不错得 refactory 包，它也可以用来完成大多数例如 symbol 补全一类得工作。唯一让人觉得有点不爽的是，它是一个版权软件，是需要 license 的。 当然，它也提供了免费试用版本下载的；同时也提供了源代码下载，你也可以试着用xref重构它自己的代码。
Chapter 9

编译你的程序
如果Emacs只能拿来写东西，那是不够的。至少，因为Emacs可以通过 M-!直接运行外部程序，所以理论上我们是可以在Emacs里面做一切事情的。嗯，理论上。
写了一点代码以后就会急急忙忙的去考虑该编译一下了。 M-x compile  就可以了。 compile 缺省命令是make -k， Emacs 会在 minibuffer  里面跳出来问，compile的命令到底应该用什么呢？如果把  compilation-read-command 设成nil，它就不会那么罗嗦了。compile使用的命令是由 compile-command ，这个变量可以自己调整。有的IDE习惯每次文件存盘的时候就会做一次编译，比如 eclipse ；如果你也有这样的偏好的话，可以吧 compile 命令放到 after-save-hook 里面去。
编译一切顺利那当然很好了，不过一般都不会是酱紫的。这个时候用 C-x `就可以跳到错误地点。 Emacs是通过对错误信息做正则匹配来找相关信息的，所以让Emacs支持特定某一个编译器是比较容易的。比如为了让 Emacs支持csc，就是csharp的compile，我们只需要：
(setq compilation-error-regexp-alist
   (append 
;;; tt.cs(5,14): error CS1585: Member modifier 'static' must precede the member type and name
    (cons '("(.*)(([0-9]+),([0-9]+)): (error|warning) CS[0-9]+:" 1 2 3) ())
     compilation-error-regexp-alist
   )
)
注意到其中的1，2，3；分别表示的是文件名，行号，列号。
Compile命令的扩展能力几乎是不受约束的，想得到的，就能支持的到。偶的想象能力比较贫乏，这里留白给更有研究精神的人来补全吧。
Chapter 10

电子邮件
10.1  收邮件，发邮件
邮件系统很早就在Emacs里面占有重要地位了。从最早的 rmail 到 vm 到  gnus ，各种各样的 mail mode ，乱花迷人眼。VM似乎是界面最友好的了，还记得第一次用 xemacs 的时候，那还是4年前，VM就已经支持很好看的图标按钮了。虽然如此，我当时对 xemacs 是如此白痴，还是没法把VM好好的用起来。
不过我转回到Emacs收信也是最近的事情了。要知道能让我从becky转过来，这个诱惑一定要不一般才可以。
gnus就提供了这样的诱惑。这个号称世界上最好的news客户端，也能作一个世界上最好的maillist客户端。如果你不上news，不混maillist，那么gnus的强大对你来说并没有意义，不如早点放弃吧。hehe
设置用gnus收信，或者发信，其实是很容易的。gnus支持多个pop3服务器， Emacs 支持smtp发信认证（需要升级你的 Emacs lisp 部分，21.3.1的还没包括这部分的内容），如果你希望 pop3 收信的时候不删除服务器上的邮件，Emacs现在还不行，你要自己动手去安装一个 epop3.el 的扩展。偶没用装过，因为偶没有这样的需求。在开始M-x gnus之前，记得在.emacs文件里面添上一些东西：
(require 'gnus-load)
(setq gnus-startup-file "~/emacs/config/newsrc")
(setq gnus-init-file "~/emacs/config/gnus-config")
把gnus-config从.emacs中分出来的做法比较清楚，因为你以后会经常有改gnus-config的需要的。在gnus-config中需要加上这些内容：
(setq gnus-select-method '(nnfolder ""))
(setq gnus-secondary-select-methods '((nntp "news.gnus.org")))
(add-to-list 'gnus-secondary-select-methods '(nntp "perl.org" (nntp-address "nntp.perl.org")))
上面的第一行指明的是gnus对邮件使用的backend，偶觉得nnfloder比较好，你可以先这样用着，反正backend以后还是可以换的，等你熟悉了 gnus以后。然后就可以给secondary-select-methods加各色的news服务器了，
(setq mail-sources '(
                     (pop :server "263.net" :user "huxwcn" :password "pighead")
                     (pop :server "knight.6test.edu.cn" :user "huxw" :password "pighead")
                     ))
然后设置 backend 去哪里收信，除了 pop3 ，还支持 imap ，或者本地的  maildir 之类的冬冬，以此类推，还能加很多。还有就是希望你不会naive 的以为上面的密码是真的。
最后，就是发信的设置。
(setq smtpmail-auth-credentials '(("smtp.263.net" 25 "huxwcn" nil)))
(setq smtpmail-smtp-server "smtp.263.net")
(setq user-full-name "Robin Hu")
(setq user-mail-address "huxw@knight.6test.edu.cn")
前两行是说发信服务器的位置，后两行是给收信人看的。人家回信就会回到那个user-mail-address 上去。以后会看到这种东西都可以很灵活的修改。
这些都搞定的时候，你就可以尝试开始gnus之旅了。我最后offer一点不好的消息，你要是觉得不爽的话，现在停止尝试gnus还来得及。因为 Emacs不是一个多线程的程序，而gnus也没有打算和别的程序合作，你打开 gnus的时候，Emacs的所有frame都会失去相应一段时间，时间的长短视 gnus把所有的邮件收回来需要的时间而定；如果你在家慢慢拨号的话，而且信有很多的话，这段时间可能会长达15分钟。事实上，news.gnus.org里面的同学似乎都是开了两个Emacs的，一个专门起gnus，另一个干活，酱紫。
好了，如果你连这个也不在乎的话，那就开始吧。M-x gnus。你会什么也看不见。这是因为gnus缺省以为，你收的邮件，都是属于某一个列表的，就好像bbs上的版面一样，你不订阅，就什么也看不见。订阅很容易，用^可以进入*Server Buffer*，在nnfolder上按RET，看到mail.misc以后按u就可以订阅它。 缺省所有没有分类的邮件都会跑到mail.misc里面去。你以后在慢慢改吧。
10.2  删除邮件
如何删除邮件，是GNUS的一个特点。
我们上bbs的时候，帖子怎么处理，不是我们说了算的，而是版主说了算了的。换句话说，帖子的生命周期是不受你掌握的，如果你想保存某一封帖子，你得把它下载到你自己的硬盘上去。gnus认为邮件也是酱紫的。在gnus里面，主动删除邮件是不提倡的，你应该让gnus自己处理邮件，被称为过期（expire）。
在缺省的设置中，你可以在一封邮件上按E，告诉gnus，这封邮件，过期了。 但是过期并不等同于删除，gnus会将这封邮件放入expire的队列中，然后等待一个特定的时间，差不多就是你真的已经忘了这封邮件的时候，gnus悄悄的删除了它。
你也可以采用auto expire模式，gnus会认为，所有你“读”过的信都是过期的，于是那些信都悄悄的自动进了过期队列，等着被删除。你还可以采用total expire模式，gnus会认为，所有你“标记为读”的信，都是过期的，于是那些信也都悄悄的进了过期队列，等着被删除。
这样的做法看起来比较诡异，但是处理邮件列表的时候却让人觉得非常自然。 所有看过就忘的信，不用去管什么时候要删除它，而且这些信在被删除之前，不会主动跳出来骚扰你；如果看到列表中某一个thread，记不起来之前这个thread到底是怎么样的，可以把这个thread没有真正删除的邮件都翻出来，显示一个完整的thread。相当于说，你总能在本地保留这个maillist最近若干天的snapshot。
对于其他信件，处理也是一样的。除非是mm发给你的一万年都不能删除的信件，别的信都可以让它自己悄悄跑进过期队列，悄悄消失。你甚至可以改变那些过期邮件的去向，不删除他们，而是把他们按时期打个包，已备若干年后写回忆录用(joking)。如果你万分肯定，这封信必须当即删除，比如不能给mm看到的别人写给你的情书，那就B del，不过这个情况很少很少，而且会导致gnus一些诡异的行为，以后再说。
罗里罗嗦了很多。expire具体的设置，都和邮件的分类联系在一起，下次再说吧，手累了。 ;-(
10.3  邮件分类
收到很多信的时候，需要分一下类。所有能用的mail客户端都支持对收到的mail做分类，包括gnus。在gnus当中，你可以通过指定的规则，将某一些邮件归成一类；在gnus看来，这样的一类邮件，基本上等同于news 服务器上的一个讨论组。
给邮件分组的工作，是通过设置nnmail-split-methods来实现的。 gnus里面所有的设置名字都很长，容易敲错，一个简单的判别方法，是在变量上面C-h v看看有没有文档。 有文档的至少能够说明这个变量名没有敲错。
我推荐使用nnmail-split-fancy来实现邮件分类，因为从个人经验来看，用fancy分类，至少可以把判别规则写的好看一点。这里先给一个sample。 
(setq nnmail-split-fancy
      '(|
;;      (: gnus-group-split-fancy)
        (any ".*-?current@(freebsd|FreeBSD).org" "maillist.freebsd.current")
        (any ".*-?ipfw@(freebsd|FreeBSD).org" "maillist.freebsd.ipfw")
        (any "emacs-devel@gnu.org" "maillist.emacs.emacs-devel")
        "mail.misc"))
(setq nnmail-split-methods 'nnmail-split-fancy)
其实就是一些正则表达式。需要注意的是，如果将 nnmail-crosspost设置为nil，那么就不会出现“一稿多投”的情况，也就是说一封邮件在这些判别规则上遇到符合的就会直接break了。还有就是不建议在这里用太复杂的正则表达式，偶曾经试图在一行里面对所有 freebsd的邮件列表进行分类，结果死的挺难看的。
一旦邮件分类了。你应该也期望对不同类别的邮件作出区别对待。林林总总的需要都可以通过设置group parameter完成。对group parameter 的设置可以在gnus里面完成，使用G p或者G c：前者是字符界面的，后者是能跳出一个类似于cunstomize的界面来。也可以通过setq gnus-parameters，在.gnus文件里面手工设定。典型的例子比如：
(setq gnus-parameters ;;别写错了名字
      '(
        ("maillist.freebsd.(.*)$"
         (to-list . "1@freebsd.org")
         (posting-style
          (name "Me me me")
          (address "me2@whoami.com")
          (signature "Smile and Retain Smile.")) ;;签名档也可以是文件
         (total-expire . t)
         (expiry-wait . 7)
         (broken-reply-to . t)
         (subscribed . t))
))
注意，这里也可以用正则表达式哦 ;-) 
group parameter 中的 to-list ，可以被自动收集起来；酱紫如果你在  nnmail-split-fancy 里面用 gnus-group-split-fancy 来自动分类，免去自己重写一遍分类规则的麻烦。不过设置gnus-parameters，是没办法利用这种能力。
设置好了 group parameter 能够简化很多事情。比如现在在 freebsd 的某个list里面按一下a，收件人地址就自动设成to-list了。很多时候比 bbdb还要方便的多。
10.4  SCORING
Chapter 11

支持中文
何曾几时，中文支持是Emacs的强项。在Emacs里面开一个shell上水木几乎是我唯一的选择。 时代变了，Emacs的中文支持就渐渐的落后了。
Emacs内部有一套表示多国的方法，就是所谓的emacs-mule。我们能够在同一个emacs buffer里面能够同时看中日韩文字，能够同时看到阿拉伯文，能够同时看到德文，丹麦文；这都拜emacs-mule所赐。不幸的是 emacs-mule并没有成为事实上的编码标准。emacs-mule除了emacs自己能够认识以外，其他的编辑器都不支持。所以Emacs必须在和其他文本处理器交互的时候重新编码内部的emacs-mule。这里没有必要谈太多的细节， Emacs是一个self-document的编辑器，上面这些细节都可以在 coding.[ch]和charset.[ch]中找到。
为了能和键盘交互（可以认为键盘是一个文本处理器，Emacs从键盘中读入文本），Emacs将从键盘中读入的文本“解码”为emacs-mule（我们这里说到编码解码，都是从Emacs的角度来看），为了文件能被其他的文本编辑器打开，比如vi，Emacs在存盘的时候将emacs-mule编码为 chinese-iso-8bit。这就是我们平常用到的各种coding system起到的作用。
为了让Emacs支持gbk，我们需要做的，就是让所有的gbk编码字符，都能够在emacs-mule中找到自己的座位。虽然实际上emacs-mule里面所有的座位都已经被人坐满了，我们还是可以假设那些很少有人出现的座位依然是空的。前面给出的chinese-gbk就强占了cns11643-5, 6, 7的座位。这些座位的汉字几乎不可能出现在我们这些人的屏幕上，所以这种做法基本上是可行的。所以如果有一天，你在使用chinese-gbk的时候，又试图用 cns11643的编码来保存，还请你回到这里来想想可能会发生的事情。
因为Emacs已经开始支持unicode了，所以让utf-8或者utf-16编码的 gbk汉字的文件在Emacs中显示并不是麻烦。而且Emacs已经在这里预留了 hook，只需要给一个 translate-table ，那就一切ok了。
让 Emacs 支持从X拷贝过来的gbk汉字，很难直接在 lisp 代码中实现。因为X和 emacs 一样是个历史悠久的软件，所以它同样也有一套自己的多字节编码格式。在 Emacs 中，缺省是采用 compound-text-with-extension 来处理这种编码格式的。从作者当初开发的思路来看，我们让它支持gbk编码，只需要添加一项 ("GBK-0" . chinese-gbk) 到 non-standard-icccm-encodings-alist中去，就可以简单的扩展支持gbk编码了。然而，因为实现上bug，和X本身的问题，这终究只是一个美好的愿望。如果你坚持的话，可以尝试一下这个补丁。注意这个时候就不能再使用 compound-text-with-extensions 作为 selection 的 coding system 了，而应该用chinese-gbk。
--- /home/huxw/src/Resp/emacs/src/xselect.c     2003-04-07 04:35:06.000000000 +0800
+++ xselect.c   2003-05-26 11:17:42.966829744 +0800
@@ -1496,6 +1496,11 @@
      Lisp_Object target_type;  /* for error messages only */
      Atom selection_atom;      /* for error messages only */
 {
+       // by huxw start here
+       XTextProperty text_prop;
+       char** local_list;
+       int local_number = 0;
+       // by huxw end here
   Atom actual_type;
   int actual_format;
   unsigned long actual_size;
@@ -1554,12 +1559,70 @@
 
   /* It's been read.  Now convert it to a lisp object in some semi-rational
      manner.  */
+  //by huxw start here
+  if (XSupportsLocale()) {
+         int local_status;
+
+         text_prop.value = (char*)data;
+         text_prop.encoding = actual_type;
+         text_prop.format = actual_format;
+         text_prop.nitems = actual_size;
+
+         local_status = XmbTextPropertyToTextList(display, &text_prop, &local_list, &local_number);
+         if (local_status < Success || !local_number || !*local_list ) {
+         } else {
+                 xfree((char*)data);
+                 data = strdup(*local_list);
+                 XFreeStringList(local_list);
+         }
+  } else {
+  }
+  //by huxw end here
+
+#if 0
   val = selection_data_to_lisp_data (display, data, bytes,
                                     actual_type, actual_format);
+#else
+       val = selection_data_to_lisp_data (display, data, strlen(data), actual_type, actual_format);
+#endif
 
   /* Use xfree, not XFree, because x_get_window_property
      calls xmalloc itself.  */
-  xfree ((char *) data);
+
+  // by huxw start here
+//  xfree ((char *) data);
+  if (local_number == 0) { // Xmb is not used or not successed
+         xfree((char*)data);
+  } else {
+         free(data);
+  }
+  // by huxw end here
   return val;
 }
Windows的国际化一向做的很好，可是Emacs没有打算依赖它。在 Windows里面跑的Emacs看起来很像在X里面跑的Emacs，很像，还是有一些要注意的地方。
 Windows 里只定义了 GB2312_CHARSET ，这把Emacs搞糊涂了。如果在 Emacs里面列出可用的所有字体，会发现没有字体是以gbk结尾的，这也使得Emacs无法处理所有gbk编码的汉字，只能显示一个方框代替。处理方法一样简单，只要把 ("gbk" w32-charset-gb2312 . 936) 加到  w32-charset-info-alist 中去就可以了。另外一个问题是Emacs有时无法正确处理字体名称中的中文编码，这种时候很是少见，找出问题之前，绕开就是了。
Windows下的粘贴拷贝并没有额外的编码，所以把  clipboard-coding-system 设成 chinese-gbk 就可以了，没有X底下的困扰。
Emacs的中文支持虽然看起很繁琐，但是它却是最完善的。比如我们知道动感超人的口号是“啊哈{6,8}”，这种正则表达除了在Emacs里面，还能在哪里用呢？
以上所说，都是针对FSF Emacs，而不是XEmacs。XEmacs的X11版本虽然也是用的 mule，但是做法稍有不同。而对于XEmacs的win32版本则根本不支持中文。XEmacs的新版本中会有不小改进，请拭目以待。

无论是在Linux还是在Unix环境中，make都是一个非常重要的编译 命令。不管是自己进行项目开发还是安装应用软件，我们都经常要用到make或make install。利用make工具，我们可以将大型的开发项目分解成为多个更易于管理的模块，对于一个包括几百个源文件的应用程序，使用make和 makefile工具就可以简洁明快地理顺各个源文件之间纷繁复杂的相互关系。而且如此多的源文件，如果每次都要键入gcc命令进行编译的话，那对程序员 来说简直就是一场灾难。而make工具则可自动完成编译工作，并且可以只对程序员在上次编译后修改过的部分进行编译。因此，有效的利用make和 makefile工具可以大大提高项目开发的效率。同时掌握make和makefile之后，您也不会再面对着Linux下的应用软件手足无措了。
　　但令人遗憾的是，在许多讲述Linux应用的书籍上都没有详细介绍这个功能强大但又非常复杂的编译工具。在这里我就向大家详细介绍一下make及其描述文件makefile。
Makefile文件
　 　Make工具最主要也是最基本的功能就是通过makefile文件来描述源程序之间的相互关系并自动维护编译工作。而makefile 文件需要按照某种语法进行编写，文件中需要说明如何编译各个源文件并连接生成可执行文件，并要求定义源文件之间的依赖关系。makefile 文件是许多编译器--包括 Windows NT 下的编译器--维护编译信息的常用方法，只是在集成开发环境中，用户通过友好的界面修改 makefile 文件而已。
　　在 UNIX 系统中，习惯使用 Makefile 作为 makfile 文件。如果要使用其他文件作为 makefile，则可利用类似下面的 make 命令选项指定 makefile 文件：
　　$ make -f Makefile.debug
　 　例如，一个名为prog的程序由三个C源文件filea.c、fileb.c和filec.c以及库文件LS编译生成，这三个文件还分别包含自己的头文 件a.h 、b.h和c.h。通常情况下，C编译器将会输出三个目标文件filea.o、fileb.o和filec.o。假设filea.c和fileb.c都要 声明用到一个名为defs的文件，但filec.c不用。即在filea.c和fileb.c里都有这样的声明：
　　#include "defs"
　　那么下面的文档就描述了这些文件之间的相互联系:
　　---------------------------------------------------------
　　　#It is a example for describing makefile
　　　prog : filea.o fileb.o filec.o
　　　cc filea.o fileb.o filec.o -LS -o prog
　　　filea.o : filea.c a.h defs
　　　cc -c filea.c
　　　fileb.o : fileb.c b.h defs
　　　cc -c fileb.c
　　　filec.o : filec.c c.h
　　　cc -c filec.c
　　----------------------------------------------------------
　 这个描述文档就是一个简单的makefile文件。
　 　从上面的例子注意到，第一个字符为 # 的行为注释行。第一个非注释行指定prog由三个目标文件filea.o、fileb.o和filec.o链接生成。第三行描述了如何从prog所依赖的 文件建立可执行文件。接下来的4、6、8行分别指定三个目标文件，以及它们所依赖的.c和.h文件以及defs文件。而5、7、9行则指定了如何从目标所 依赖的文件建立目标。
　　当filea.c或a.h文件在编译之后又被修改，则 make 工具可自动重新编译filea.o，如果在前后两次编译之间，filea.C 和a.h 均没有被修改，而且 test.o 还存在的话，就没有必要重新编译。这种依赖关系在多源文件的程序编译中尤其重要。通过这种依赖关系的定义，make 工具可避免许多不必要的编译工作。当然，利用 Shell 脚本也可以达到自动编译的效果，但是，Shell 脚本将全部编译任何源文件，包括哪些不必要重新编译的源文件，而 make 工具则可根据目标上一次编译的时间和目标所依赖的源文件的更新时间而自动判断应当编译哪个源文件。
Makefile文件作为一种描述文档一般需要包含以下内容:
　　◆ 宏定义
　　◆ 源文件之间的相互依赖关系
　　◆ 可执行的命令
　　Makefile中允许使用简单的宏指代源文件及其相关编译信息，在Linux中也称宏为变量。在引用宏时只需在变量前加$符号，但值得注意的是，如果变量名的长度超过一个字符，在引用时就必须加圆括号（）。
　　下面都是有效的宏引用：
　　$(CFLAGS)
　　$2
　　$Z
　　$(Z)
　　其中最后两个引用是完全一致的。
　　需要注意的是一些宏的预定义变量，在Unix系统中，$*、$@、$?和$<四个特殊宏的值在执行命令的过程中会发生相应的变化，而在GNU make中则定义了更多的预定义变量。关于预定义变量的详细内容，
　　宏定义的使用可以使我们脱离那些冗长乏味的编译选项，为编写makefile文件带来很大的方便。
　　---------------------------------------------------------
　　　# Define a macro for the object files
　　　OBJECTS= filea.o fileb.o filec.o
　　　# Define a macro for the library file
　　　LIBES= -LS
　　　# use macros rewrite makefile
　　　prog: $(OBJECTS)
　　　cc $(OBJECTS) $(LIBES) -o prog
　　　……
　　---------------------------------------------------------
　　此时如果执行不带参数的make命令，将连接三个目标文件和库文件LS；但是如果在make命令后带有新的宏定义：
　　make "LIBES= -LL -LS"
则命令行后面的宏定义将覆盖makefile文件中的宏定义。若LL也是库文件，此时make命令将连接三个目标文件以及两个库文件LS和LL。
　　在Unix系统中没有对常量NULL作出明确的定义，因此我们要定义NULL字符串时要使用下述宏定义：
　　STRINGNAME=
Make命令
　　在make命令后不仅可以出现宏定义，还可以跟其他命令行参数，这些参数指定了需要编译的目标文件。其标准形式为：
　　target1 [target2 …]:[:][dependent1 …][;commands][#…]
　　[(tab) commands][#…]
　　方括号中间的部分表示可选项。Targets和dependents当中可以包含字符、数字、句点和"/"符号。除了引用，commands中不能含有"#",也不允许换行。
　 　在通常的情况下命令行参数中只含有一个":"，此时command序列通常和makefile文件中某些定义文件间依赖关系的描述行有关。如果与目标相 关连的那些描述行指定了相关的command序列，那么就执行这些相关的command命令，即使在分号和(tab)后面的aommand字段甚至有可能 是NULL。如果那些与目标相关连的行没有指定command，那么将调用系统默认的目标文件生成规则。
　　如果命令行参数中含有两个冒号"::"，则此时的command序列也许会和makefile中所有描述文件依赖关系的行有关。此时将执行那些与目标相关连的描述行所指向的相关命令。同时还将执行build-in规则。
　　如果在执行command命令时返回了一个非"0"的出错信号，例如makefile文件中出现了错误的目标文件名或者出现了以连字符打头的命令字符串，make操作一般会就此终止，但如果make后带有"-i"参数，则make将忽略此类出错信号。
　　Make命本身可带有四种参数：标志、宏定义、描述文件名和目标文件名。其标准形式为：
　　Make [flags] [macro definitions] [targets]
　　Unix系统下标志位flags选项及其含义为：
　 　-f file　 指定file文件为描述文件，如果file参数为"-"符，那么描述文件指向标准输入。如果没有"-f"参数，则系统将默认当前目录下名为 makefile或者名为Makefile的文件为描述文件。在Linux中， GNU make 工具在当前工作目录中按照GNUmakefile、makefile、Makefile的顺序搜索 makefile文件。
　　-i 　　忽略命令执行返回的出错信息。
　　-s 　　沉默模式，在执行之前不输出相应的命令行信息。
　　-r 　　禁止使用build-in规则。
　　-n 　　非执行模式，输出所有执行命令，但并不执行。
　　-t 　　更新目标文件。
　　-q　　 make操作将根据目标文件是否已经更新返回"0"或非"0"的状态信息。
　　-p　　 输出所有宏定义和目标文件描述。
　　-d　　 Debug模式，输出有关文件和检测时间的详细信息。
　　Linux下make标志位的常用选项与Unix系统中稍有不同，下面我们只列出了不同部分：
　　-c dir　　 在读取 makefile 之前改变到指定的目录dir。
　　-I dir 　　当包含其他 makefile文件时，利用该选项指定搜索目录。
　　-h 　　help文挡，显示所有的make选项。
　　-w 　　在处理 makefile 之前和之后，都显示工作目录。
　　通过命令行参数中的target ，可指定make要编译的目标，并且允许同时定义编译多个目标，操作时按照从左向右的顺序依次编译target选项中指定的目标文件。如果命令行中没有指定目标，则系统默认target指向描述文件中第一个目标文件。
　　通常，makefile 中还定义有 clean 目标，可用来清除编译过程中的中间文件，例如：
　　clean:
　　rm -f *.o
　　运行 make clean 时，将执行 rm -f *.o 命令，最终删除所有编译过程中产生的所有中间文件。
隐含规则
　 　在make 工具中包含有一些内置的或隐含的规则，这些规则定义了如何从不同的依赖文件建立特定类型的目标。Unix系统通常支持一种基于文件扩展名即文件名后缀的隐 含规则。这种后缀规则定义了如何将一个具有特定文件名后缀的文件（例如.c文件），转换成为具有另一种文件名后缀的文件（例如.o文件）：
　　.c:.o
　　$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<
　　系统中默认的常用文件扩展名及其含义为：
　　.o 　目标文件
　　.c 　C源文件
　　.f 　FORTRAN源文件
　　.s 　汇编源文件
　　.y 　Yacc-C源语法
　　.l 　Lex源语法
　 　在早期的Unix系统系统中还支持Yacc-C源语法和Lex源语法。在编译过程中，系统会首先在makefile文件中寻找与目标文件相关的.C文 件，如果还有与之相依赖的.y和.l文件，则首先将其转换为.c文件后再编译生成相应的.o文件；如果没有与目标相关的.c文件而只有相关的.y文件，则 系统将直接编译.y文件。
　　而GNU make 除了支持后缀规则外还支持另一种类型的隐含规则--模式规则。这种规则更加通用，因为可以利用模式规则定义更加复杂的依赖性规则。模式规则看起来非常类似 于正则规则，但在目标名称的前面多了一个 % 号，同时可用来定义目标和依赖文件之间的关系，例如下面的模式规则定义了如何将任意一个 file.c 文件转换为 file.o 文件：
　　%.c:%.o
　　$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<
#EXAMPLE#
　 　下面将给出一个较为全面的示例来对makefile文件和make命令的执行进行进一步的说明，其中make命令不仅涉及到了C源文件还包括了Yacc 语法。本例选自"Unix Programmer's Manual 7th Edition, Volume 2A" Page 283-284
　　下面是描述文件的具体内容：
　　---------------------------------------------------------
　　　#Description file for the Make command
　　　#Send to print
　　　P=und -3 | opr -r2
　　　#The source files that are needed by object files
　　　FILES= Makefile version.c defs main.c donamc.c misc.c file.c
　　　dosys.c gram.y lex.c gcos.c
　　　#The definitions of object files
　　　OBJECTS= vesion.o main.o donamc.o misc.o file.o dosys.o gram.o
　　　LIBES= -LS
　　　LINT= lnit -p
　　　CFLAGS= -O
　　　make: $(OBJECTS)
　　　cc $(CFLAGS) $(OBJECTS) $(LIBES) -o make
　　　size make
　　　$(OBJECTS): defs
　　　gram.o: lex.c
　　　cleanup:
　　　-rm *.o gram.c
　　　install:
　　　@size make /usr/bin/make
　　　cp make /usr/bin/make ; rm make
　　　#print recently changed files
　　　print: $(FILES)
　　　pr $? | $P
　　　touch print
　　　test:
　　　make -dp | grep -v TIME>1zap
　　　/usr/bin/make -dp | grep -v TIME>2zap
　　　diff 1zap 2zap
　　　rm 1zap 2zap
　　　lint: dosys.c donamc.c file.c main.c misc.c version.c gram.c
　　　$(LINT) dosys.c donamc.c file.c main.c misc.c version.c
　　　gram.c
　　　rm gram.c
　　　arch:
　　　ar uv /sys/source/s2/make.a $(FILES)
　　----------------------------------------------------------
　　通常在描述文件中应象上面一样定义要求输出将要执行的命令。在执行了make命令之后，输出结果为：
　　$ make
　　cc -c version.c
　　cc -c main.c
　　cc -c donamc.c
　　cc -c misc.c
　　cc -c file.c
　　cc -c dosys.c
　　yacc gram.y
　　mv y.tab.c gram.c
　　cc -c gram.c
　　cc version.o main.o donamc.o misc.o file.o dosys.o gram.o
　　-LS -o make
　　13188+3348+3044=19580b=046174b

　　最后的数字信息是执行"@size make"命令的输出结果。之所以只有输出结果而没有相应的命令行，是因为"@size make"命令以"@"起始，这个符号禁止打印输出它所在的命令行。
　 　描述文件中的最后几条命令行在维护编译信息方面非常有用。其中"print"命令行的作用是打印输出在执行过上次"make print"命令后所有改动过的文件名称。系统使用一个名为print的0字节文件来确定执行print命令的具体时间，而宏$?则指向那些在print 文件改动过之后进行修改的文件的文件名。如果想要指定执行print命令后，将输出结果送入某个指定的文件，那么就可修改P的宏定义：
　　make print "P= cat>zap"
　　在Linux中大多数软件提供的是源代码，而不是现成的可执行文件，这就要求用户根据自己系统的实际情况和自身的需要来配置、编译源程序后，软件才能使用。只有掌握了make工具，才能让我们真正享受到到Linux这个自由软件世界的带给我们无穷乐趣。

http://www.chinaunix.net 作者:蓝色键盘 发表于：2003-05-09 14:01:19

经常的，有朋友问到有关unix下面条是的技术。我整理了大多数的unix系统下面的常用的调试工具的调试技术的文章。希望对大家有所帮助。

另外静态库、动态库也是问的频率比较高的问题。在这里也做了总结。

＃＃＃＃＃＃大多数unix系统下面的调试器的使用方法如下：＃＃＃＃＃＃

***************gdb介绍*********************
GNU 的调试器称为 gdb，该程序是一个交互式工具，工作在字符模式。在 X Window 系统中，有一个 gdb 的
前端图形工具，称为 xxgdb。gdb 是功能强大的调试程序，可完成如下的调试任务：
* 设置断点；
* 监视程序变量的值；
* 程序的单步执行；
* 修改变量的值。
在可以使用 gdb 调试程序之前，必须使用 -g 选项编译源文件。可在 makefile 中如下定义 CFLAGS 变量：
CFLAGS = -g
运行 gdb 调试程序时通常使用如下的命令：
gdb progname

在 gdb 提示符处键入help，将列出命令的分类，主要的分类有：
* aliases：命令别名
* breakpoints：断点定义；
* data：数据查看；
* files：指定并查看文件；
* internals：维护命令；
* running：程序执行；
* stack：调用栈查看；
* statu：状态查看；
* tracepoints：跟踪程序执行。
键入 help 后跟命令的分类名，可获得该类命令的详细清单。

*********gdb 的常用命令***************
命令 解释
break NUM 在指定的行上设置断点。
bt 显示所有的调用栈帧。该命令可用来显示函数的调用顺序。
clear 删除设置在特定源文件、特定行上的断点。其用法为：clear FILENAME:NUM。
continue 继续执行正在调试的程序。该命令用在程序由于处理信号或断点而
导致停止运行时。
display EXPR 每次程序停止后显示表达式的值。表达式由程序定义的变量组成。
file FILE 装载指定的可执行文件进行调试。
help NAME 显示指定命令的帮助信息。
info break 显示当前断点清单，包括到达断点处的次数等。
info files 显示被调试文件的详细信息。
info func 显示所有的函数名称。
info local 显示当函数中的局部变量信息。
info prog 显示被调试程序的执行状态。
info var 显示所有的全局和静态变量名称。
kill 终止正被调试的程序。
list 显示源代码段。
make 在不退出 gdb 的情况下运行 make 工具。
next 在不单步执行进入其他函数的情况下，向前执行一行源代码。
print EXPR 显示表达式 EXPR 的值。

******gdb 使用范例************************
-----------------
清单 一个有错误的 C 源程序 bugging.c
-----------------
#include
#include

static char buff [256];
static char* string;
int main ()
{

printf ("Please input a string: ");
gets (string);

printf ("nYour string is: %sn", string);
}
-----------------
上面这个程序非常简单，其目的是接受用户的输入，然后将用户的输入打印出来。该程序使用了一个未经过初
始化的字符串地址 string，因此，编译并运行之后，将出现 Segment Fault 错误：
$ gcc -o test -g test.c
$ ./test
Please input a string: asfd
Segmentation fault (core dumped)
为了查找该程序中出现的问题，我们利用 gdb，并按如下的步骤进行：
1．运行 gdb bugging 命令，装入 bugging 可执行文件；
2．执行装入的 bugging 命令；
3．使用 where 命令查看程序出错的地方；
4．利用 list 命令查看调用 gets 函数附近的代码；
5．唯一能够导致 gets 函数出错的因素就是变量 string。用 print 命令查看 string 的值；
6．在 gdb 中，我们可以直接修改变量的值，只要将 string 取一个合法的指针值就可以了，为此，我们在第
11 行处设置断点；
7．程序重新运行到第 11 行处停止，这时，我们可以用 set variable 命令修改 string 的取值；
8．然后继续运行，将看到正确的程序运行结果。

运行 gcc/egcs

**********运行 gcc/egcs***********************
GCC 是 GNU 的 C 和 C++ 编译器。实际上，GCC 能够编译三种语言：C、C++ 和 Object C（C 语言的一种面向对象扩展）。利用 gcc 命令可同时编译并连接 C 和 C++ 源程序。

如果你有两个或少数几个 C 源文件，也可以方便地利用 GCC 编译、连接并生成可执行文件。例如，假设你有
两个源文件 main.c 和 factorial.c 两个源文件，现在要编译生成一个计算阶乘的程序。
清单 factorial.c
-----------------------
#include
#include

int factorial (int n)
{
if (n <= 1)
return 1;

else
return factorial (n - 1) * n;
}
-----------------------

-----------------------
清单 main.c
-----------------------
#include
#include

int factorial (int n);

int main (int argc, char **argv)
{
int n;

if (argc < 2) {
printf ("Usage: %s nn", argv [0]);
return -1;
}
else {
n = atoi (argv[1]);
printf ("Factorial of %d is %d.n", n, factorial (n));
}

return 0;
}
-----------------------
利用如下的命令可编译生成可执行文件，并执行程序：
$ gcc -o factorial main.c factorial.c
$ ./factorial 5
Factorial of 5 is 120.

GCC 可同时用来编译 C 程序和 C++ 程序。一般来说，C 编译器通过源文件的后缀名来判断是 C 程序还是 C+
+ 程序。在 Linux 中，C 源文件的后缀名为 .c，而 C++ 源文件的后缀名为 .C 或 .cpp。
但是，gcc 命令只能编译 C++ 源文件，而不能自动和 C++ 程序使用的库连接。因此，通常使用 g++ 命令来完
完成 C++ 程序的编译和连接，该程序会自动调用 gcc 实现编译。
假设我们有一个如下的 C++ 源文件（hello.C）：

#include

void main (void)
{
cout << "Hello, world!" << endl;
}

则可以如下调用 g++ 命令编译、连接并生成可执行文件：

$ g++ -o hello hello.C
$ ./hello
Hello, world!

**********************gcc/egcs 的主要选项*********
gcc 命令的常用选项
选项 解释
-ansi 只支持 ANSI 标准的 C 语法。这一选项将禁止 GNU C 的某些特色，
例如 asm 或 typeof 关键词。
-c 只编译并生成目标文件。
-DMACRO 以字符串“1”定义 MACRO 宏。
-DMACRO=DEFN 以字符串“DEFN”定义 MACRO 宏。
-E 只运行 C 预编译器。
-g 生成调试信息。GNU 调试器可利用该信息。
-IDIRECTORY 指定额外的头文件搜索路径DIRECTORY。
-LDIRECTORY 指定额外的函数库搜索路径DIRECTORY。
-lLIBRARY 连接时搜索指定的函数库LIBRARY。
-m486 针对 486 进行代码优化。
-o FILE 生成指定的输出文件。用在生成可执行文件时。
-O0 不进行优化处理。
-O 或 -O1 优化生成代码。
-O2 进一步优化。
-O3 比 -O2 更进一步优化，包括 inline 函数。
-shared 生成共享目标文件。通常用在建立共享库时。
-static 禁止使用共享连接。
-UMACRO 取消对 MACRO 宏的定义。
-w 不生成任何警告信息。
-Wall 生成所有警告信息。

＃＃＃＃＃＃＃SCO UNIX下面dbaxtra的调试技术＃＃＃＃＃＃＃＃＃
在sco unix下编程大多离不开C语言，即使是数据库应用也有很多是与c搭配使用的，例如informix esql/c 就可以在c语言中嵌入sql 语句。很多人认为在unix下写程序是件很痛苦的事情，其中一个很重要原因是不知道在unix下怎样调试程序。其实在sco unix源码调试器是dbxtra或dbXtra，linux下是gdb。它们类似turbo c的调试器,可以跟踪源码变量。在unix 下调试程序有如下传统方法

---- 一、在要调试语句之前，输出要调试的变量，利用printf()函数。

---- 二、写日志文件，把结果输出到文件中避免屏幕混乱，利用fprintf()函数。

---- 三、利用sco 内置调试器dbxtra或dbXtra。

---- dbxtra 适用字符界面，在sco unix的图形界面用dbXtra。(编按：请注意大小写)

以下是dbxtra基本命令：
c cont 在断点后继续执行
d delete 删除所设断点
h help 帮助
e edit 编辑源程序
n next 源程序区的内容向下翻一屏。
p print 显示变量
q quit 退出dbxtra
r run 运行程序，直到遇上设置的断点
rr rerun 再次运行
s step 单步运行
st stop 设置断点
j status 显示当前断点
t where 显示当前状态，列出所有设置的变量值
di display 开显示窗，用于查看变量
ud undisplay 删除显示窗的条目
f forward 源程序区的内容向上 翻一屏。
B backward 源程序区的内容向下 翻一屏。
Stopi stop inst 设置断点
tracei trace inst跟踪子程序

dbxtra [options] [objectfile ]

---- dbxtra 在启动时有个参数-Idir值得一提.我们在编写一个较大程序的时候，通常源程序和编译生成的可执行文件都放在不同的目录中，这样便于管理。默认dbxtra将在可执行文件所在的目录下找匹配c的源程序。当我们启动时，指定-I参数，dbxtra就会到我们指定的目录下找匹配的c程序。 例如：
---- dbxtra -I"workc" program1

---- 源程序在用cc编译时要带上-g 参数，这样是加上符号表等调试信息。只有这样编译过的文件，dbxtra才可以调试。调试信息使源代码和机器码关联。

---- 下面这个C程序输出结果和我们的预想结果不一样，说明某些地方有错误。我们用调试器来调试它：

---- 程序一:

t.c
main()
{ int i=10 ,*p1;
float j=1.5,*p2;
p1=&
p2=&
p2=p1;
printf("%d,%dn",*p1,*p2);
}

首先带上-g参数编译 cc -g -o t t.c
启动调试器 dbxtra t
屏幕显示：
1.main()
2.{ int i=10 ,*p1;
3. float j=1.5,*p2;
4. p1=&
5. p2=&
6. p2=p1;
7. printf("%d,%dn",*p1,*p2);
8.}
C[browse] File:t.c Func.-
Readubg symbolic information
Type 'help' for help
(dbxtra)
(dbxtra)

设置断点：
(dbxtra）stop at 5
运行：
(dbxtra) run
程序自动在第5行停下。
这时我们可以看变量的值。
(dbxtra) print *p1

单步执行。
(dbxtra) step
程序将执行第5行源码，指针将移到第6行。
(dbxtra) print *p2

(dbxtra） step
程序执行了第6行源码后，将指针移到第7行。
(dbxtra） print *p1 , *p2

---- 我们发现 在执行了第6行源码后，*p1,*p2的值就不对了，所以问题就出在第6行上。仔细检查后发现指针p1指向整型，指针p2指向实型。它们之间的赋值要进行强制类型转换。这种错误在C程序中是很常见的。
---- 有时我们在调试一些程序时，要在整个程序运行中时刻监视莫些变量的值，例如程序一中我们要时刻了解*p1,*p2的值，除了在每一行程序执行完后，打print *p1,*p2外，还可以开一个显示窗口。

---- (dbxtra）display *p1,*p2

---- 用undisplay 删掉不想要的变量。

---- 有些程序运行时要带参数，mycat /etc/passwd 在调试时候

---- (dbxtra) run '/etc/passwd'

---- 再运行时，无需再写一遍参数。

---- (dbxtra） rerun

---- 在涉及到curses库编程或屏幕有大量的人机界面时，为了调试方便，我们可以把程序输出结果重定向到个虚屏。

---- (dbxtra） run >/dev/tty03

---- 当然要先把tty03 disable 掉。（disable tty03）

＃＃＃＃＃＃＃创建和使用静态库＃＃＃＃＃＃＃＃＃

详细的使用情况，请大家man手册，这里只介绍一下。静态库相对的比较简单。

创建一个静态库是相当简单的。通常使用 ar 程序把一些目标文件（.o）组合在一起，
成为一个单独的库，然后运行 ranlib，以给库加入一些索引信息。

＃＃＃＃＃＃＃＃创建和使用共享库＃＃＃＃＃＃＃＃＃
特殊的编译和连接选项
-D_REENTRANT 使得预处理器符号 _REENTRANT 被定义，这个符号激活一些宏特性。
-fPIC 选项产生位置独立的代码。由于库是在运行的时候被调入，因此这个
选项是必需的，因为在编译的时候，装入内存的地址还不知道。如果
不使用这个选项，库文件可能不会正确运行。
-shared 选项告诉编译器产生共享库代码。
-Wl,-soname -Wl 告诉编译器将后面的参数传递到连接器。而 -soname 指定了
共享库的 soname。
＃ 可以把库文件拷贝到 /etc/ld.so.conf 中列举出的任何目录中，并以
root 身份运行 ldconfig；或者
＃ 运行 export LD_LIBRARY_PATH='pwd'，它把当前路径加到库搜索路径中去。

＃＃＃＃＃＃＃使用高级共享库特性＃＃＃＃＃＃＃＃＃

1. ldd 工具
ldd 用来显示执行文件需要哪些共享库, 共享库装载管理器在哪里找到了需要的共享库.

2. soname

共享库的一个非常重要的，也是非常难的概念是 soname——简写共享目标名（short for shared object name）。这是一个为共享库（.so）文件而内嵌在控制数据中的名字。如前面提到的，每一个程序都有一个需要使用的库的清单。这个清单的内容是一系列库的 soname，如同 ldd 显示的那样，共享库装载器必须找到这个清单。

soname 的关键功能是它提供了兼容性的标准。当要升级系统中的一个库时，并且新库的 soname 和老的库的 soname 一样，用旧库连接生成的程序，使用新的库依然能正常运行。这个特性使得在 Linux 下，升级使用共享库的程序和定位错误变得十分容易。

在 Linux 中，应用程序通过使用 soname，来指定所希望库的版本。库作者也可以通过保留或者改变 soname 来声明，哪些版本是相互兼容的，这使得程序员摆脱了共享库版本冲突问题的困扰。

查看/usr/local/lib 目录，分析 MiniGUI 的共享库文件之间的关系

3. 共享库装载器

当程序被调用的时候，Linux 共享库装载器（也被称为动态连接器）也自动被调用。它的作用是保证程序所需要的所有适当版本的库都被调入内存。共享库装载器名字是 ld.so 或者是 ld-linux.so，这取决于 Linux libc 的版本，它必须使用一点外部交互，才能完成自己的工作。然而它接受在环境变量和配置文件中的配置信息。

文件 /etc/ld.so.conf 定义了标准系统库的路径。共享库装载器把它作为搜索路径。为了改变这个设置，必须以 root 身份运行 ldconfig 工具。这将更新 /etc/ls.so.cache 文件，这个文件其实是装载器内部使用的文件之一。

可以使用许多环境变量控制共享库装载器的操作（表1-4+）。

表 1-4+ 共享库装载器环境变量
变量 含义
LD_AOUT_LIBRARY_PATH 除了不使用 a.out 二进制格式外，与 LD_LIBRARY_PATH 相同。
LD_AOUT_PRELOAD 除了不使用 a.out 二进制格式外，与 LD_PRELOAD 相同。
LD_KEEPDIR 只适用于 a.out 库；忽略由它们指定的目录。
LD_LIBRARY_PATH 将其他目录加入库搜索路径。它的内容应该是由冒号
分隔的目录列表，与可执行文件的 PATH 变量具有相同的格式。
如果调用设置用户 ID 或者进程 ID 的程序，该变量被忽略。
LD_NOWARN 只适用于 a.out 库；当改变版本号是，发出警告信息。
LD_PRELOAD 首先装入用户定义的库，使得它们有机会覆盖或者重新定义标准库。
使用空格分开多个入口。对于设置用户 ID 或者进程 ID 的程序，
只有被标记过的库才被首先装入。在 /etc/ld.so.perload 中指定
了全局版本号，该文件不遵守这个限制。

4. 使用 dlopen

另外一个强大的库函数是 dlopen()。该函数将打开一个新库，并把它装入内存。该函数主要用来加载库中的符号，这些符号在编译的时候是不知道的。比如 Apache Web 服务器利用这个函数在运行过程中加载模块，这为它提供了额外的能力。一个配置文件控制了加载模块的过程。这种机制使得在系统中添加或者删除一个模块时，都不需要重新编译了。

可以在自己的程序中使用 dlopen()。dlopen() 在 dlfcn.h 中定义，并在 dl 库中实现。它需要两个参数：一个文件名和一个标志。文件名可以是我们学习过的库中的 soname。标志指明是否立刻计算库的依赖性。如果设置为 RTLD_NOW 的话，则立刻计算；如果设置的是 RTLD_LAZY，则在需要的时候才计算。另外，可以指定 RTLD_GLOBAL，它使得那些在以后才加载的库可以获得其中的符号。

当库被装入后，可以把 dlopen() 返回的句柄作为给 dlsym() 的第一个参数，以获得符号在库中的地址。使用这个地址，就可以获得库中特定函数的指针，并且调用装载库中的相应函数。

一、编写合格的动态链接库头文件

C语言的头文件,可供一个或多个程序引用,里面一般定义程序所需的常量,自定义类型及函数原型说明等.其中的函数原型说明,则供编译器检查语法,用于排除引用参数时类型不一致的错误.只有编写合格的动态链接库头文件,程序员才能正确使用动态链接库内的函数.

动态链接库头文件要采用C语言标准格式,其中的动态函数原型定义,不必象上文介绍的那样用(*动态函数名)的描述形式.请看下面的例子每行开始的数字为所在行行号,为笔者添加,供注解使用)

1 /* adatetime.h : 纵横软件制作中心雨亦奇(zhsoft@371.net)编写, 2002-03-06. */
2
3 #ifndef __DATETIME_H
4
5 #define __DATETIME_H
6
7 /* 日期结构 */
8 typedef struct
9 {
10 int year;
11 int mon;
12 int day;
13 }DATETYPE;
14
15 /* 时间结构 */
16 typedef struct
17 {
18 char hour;
19 char min;
20 char sec;
21 }TIMETYPE;
22
23 int getdate(DATETYPE *d); /* 取当前日期 */
24 int gettime(TIMETYPE *t); /* 取当前时间 */
25
26 #endif
27

注:与上文的datetime.h文件比较,从该头文件第23,24行可以看到,动态函数getdate,gettime的原型定义改变了,不再使用(*getdate),(*gettime)的格式了(这种格式使用较为罗嗦).

二、正确编译与命名动态链接库

为了让GCC编译器生成动态链接库,编译时须加选项-shared.(这点须牢记)

LINUX系统中,为了让动态链接库能被系统中其它程序共享,其名字应符合“lib*.so*”这种格式.如果某个动态链接库不符合此格式,则LINUX的动态链接库自动装入程序(ld.so)将搜索不到此链接库,其它程序也无法共享之.

格式中,第一个*通常表示为简写的库名,第二个*通常表示为该库的版本号.如:在我的系统中,基本C动态链接库的名字为libc.so.6,线程pthread动态链接库的名字为libpthread.so.0等等.本文例子所生成的动态链接库的名字为libmy.so,虽没有版本号,但也符合所要求的格式.

生成该动态链接库的维护文件makefile-lib内容如下:

1 # makefile : 纵横软件制作中心雨亦奇编写, 2002-03-07.
2
3 all : libmy.so
4
5 SRC = getdate.c gettime.c
6
7 TGT = $(SRC:.c=.o)
8
9 $(SRC) : adatetime.h
10 @touch $@
11
12 %.o : %.c
13 cc -c $?
14
15 # 动态链接库(libmy.so)生成
16 libmy.so : $(TGT)
17 cc -s -shared -o $@ $(TGT)
18

运行命令:

$ make -f makefile-lib
$

即生成libmy.so库.

注: 维护文件中,第17行用-shared选项以生成动态链接库,用-s选项以去掉目标文件中的符号表,从而减小文件长度.

三、共享动态链接库

3.1 动态链接库配置文件

为了让动态链接库为系统所使用,需要维护动态链接库的配置文件--/etc/ld.so.conf.此文件内,存放着可被LINUX共享的动态链接库所在目录的名字(系统目录/lib,/usr/lib除外),各个目录名间以空白字符(空格,换行等)或冒号或逗号分隔.一般的LINUX发行版中,此文件均含一个共享目录/usr/X11R6/lib,为X window窗口系统的动态链接库所在的目录.

下面看看我的系统中此文件的内容如何:

# cat /etc/ld.so.conf
/usr/X11R6/lib
/usr/zzz/lib
#

由上可以看出,该动态库配置文件中,增加了一个/usr/zzz/lib目录.这是我自己新建的共享库目录,下面存放我新开发的可供系统共享的动态链接库.

3.2 动态链接库管理命令

为了让动态链接库为系统所共享,还需运行动态链接库的管理命令--ldconfig.此执行程序存放在/sbin目录下.

ldconfig命令的用途,主要是在默认搜寻目录(/lib和/usr/lib)以及动态库配置文件/etc/ld.so.conf内所列的目录下,搜索出可共享的动态链接库(格式如前介绍,lib*.so*),进而创建出动态装入程序(ld.so)所需的连接和缓存文件.缓存文件默认为/etc/ld.so.cache,此文件保存已排好序的动态链接库名字列表.

ldconfig通常在系统启动时运行,而当用户安装了一个新的动态链接库时,就需要手工运行这个命令.

ldconfig命令行用法如下:

ldconfig [-v|--verbose] [-n] [-N] [-X] [-f CONF] [-C CACHE] [-r ROOT] [-l] [-p|--print-cache] [-c FORMAT] [--format=FORMAT] [-V] [-?|--help|--usage] path...

ldconfig可用的选项说明如下:

(1) -v或--verbose : 用此选项时,ldconfig将显示正在扫描的目录及搜索到的动态链接库,还有它所创建的连接的名字.

(2) -n : 用此选项时,ldconfig仅扫描命令行指定的目录,不扫描默认目录(/lib,/usr/lib),也不扫描配置文件/etc/ld.so.conf所列的目录.

(3) -N : 此选项指示ldconfig不重建缓存文件(/etc/ld.so.cache).若未用-X选项,ldconfig照常更新文件的连接.

(4) -X : 此选项指示ldconfig不更新文件的连接.若未用-N选项,则缓存文件正常更新.

(5) -f CONF : 此选项指定动态链接库的配置文件为CONF,系统默认为/etc/ld.so.conf.

(6) -C CACHE : 此选项指定生成的缓存文件为CACHE,系统默认的是/etc/ld.so.cache,此文件存放已排好序的可共享的动态链接库的列表.

(7) -r ROOT : 此选项改变应用程序的根目录为ROOT(是调用chroot函数实现的).选择此项时,系统默认的配置文件/etc/ld.so.conf,实际对应的为ROOT/etc/ld.so.conf.如用-r /usr/zzz时,打开配置文件/etc/ld.so.conf时,实际打开的是/usr/zzz/etc/ld.so.conf文件.用此选项,可以大大增加动态链接库管理的灵活性.

( -l : 通常情况下,ldconfig搜索动态链接库时将自动建立动态链接库的连接.选择此项时,将进入专家模式,需要手工设置连接.一般用户不用此项.

(9) -p或--print-cache : 此选项指示ldconfig打印出当前缓存文件所保存的所有共享库的名字.

(10) -c FORMAT 或 --format=FORMAT : 此选项用于指定缓存文件所使用的格式,共有三种ld(老格式),new(新格式)和compat(兼容格式,此为默认格式).

(11) -V : 此选项打印出ldconfig的版本信息,而后退出.

(12) -? 或 --help 或 --usage : 这三个选项作用相同,都是让ldconfig打印出其帮助信息,而后退出.

举三个例子:

例1:

# ldconfig -p
793 libs found in cache `/etc/ld.so.cache'
libzvt.so.2 (libc6) => /usr/lib/libzvt.so.2
libzvt.so (libc6) => /usr/lib/libzvt.so
libz.so.1.1.3 (libc6) => /usr/lib/libz.so.1.1.3
libz.so.1 (libc6) => /lib/libz.so.1
......
#

注: 有时候用户想知道系统中有哪些动态链接库,或者想知道系统中有没有某个动态链接库,这时,可用-p选项让ldconfig输出缓存文件中的动态链接库列表,从而查询得到.例子中,ldconfig命令的输出结果第1行表明在缓存文件/etc/ld.so.cache中找到793个共享库,第2行开始便是一系列共享库的名字及其全名(绝对路径).因为实际输出结果太多,为节省篇幅,以......表示省略的部分.

例2:

# ldconfig -v
/lib:
liby.so.1 -> liby.so.1
libnss_wins.so -> libnss_wins.so
......
/usr/lib:
libjscript.so.2 -> libjscript.so.2.0.0
libkspell.so.2 -> libkspell.so.2.0.0
......
/usr/X11R6/lib:
libmej-0.8.10.so -> libmej-0.8.10.so
libXaw3d.so.7 -> libXaw3d.so.7.0
......
#

注: ldconfig命令在运行正常的情况下,默认不输出什么东西.本例中用了-v选项,以使ldconfig在运行时输出正在扫描的目录及搜索到的共享库,用户可以清楚地看到运行的结果.执行结束后,ldconfig将刷新缓存文件/etc/ld.so.cache.

例3:

# ldconfig /usr/zhsoft/lib
#

注: 当用户在某个目录下面创建或拷贝了一个动态链接库,若想使其被系统共享,可以执行一下"ldconfig 目录名"这个命令.此命令的功能在于让ldconfig将指定目录下的动态链接库被系统共享起来,意即:在缓存文件/etc/ld.so.cache中追加进指定目录下的共享库.本例让系统共享了/usr/zhsoft/lib目录下的动态链接库.需要说明的是,如果此目录不在/lib,/usr/lib及/etc/ld.so.conf文件所列的目录里面,则再度运行ldconfig时,此目录下的动态链接库可能不被系统共享了.

3.3 动态链接库如何共享

了解了以上知识,我们可以采用以下三种方法来共享动态链接库注:均须在超级用户状态下操作,以我的动态链接库libmy.so共享过程为例)

(1)拷贝动态链接库到系统共享目录下,或在系统共享目录下为该动态链接库建立个连接(硬连接或符号连接均可,常用符号连接).这里说的系统共享目录,指的是LINUX动态链接库存放的目录,它包含/lib,/usr/lib以及/etc/ld.so.conf文件内所列的一系列目录.

# cp libmy.so /lib
# ldconfig
#

或:

# ln -s `pwd`/libmy.so /lib
# ldconfig
#

(2)将动态链接库所在目录名追加到动态链接库配置文件/etc/ld.so.conf中.

# pwd >> /etc/ld.so.conf
# ldconfig
#

(3)利用动态链接库管理命令ldconfig,强制其搜索指定目录,并更新缓存文件,便于动态装入.

# ldconfig `pwd`
#

需要说明的是,这种操作方法虽然有效,但效果是暂时的,供程序测试还可以,一旦再度运行ldconfig,则缓存文件内容可能改变,所需的动态链接库可能不被系统共享了.与之相比较,前两种方法是可靠的方法,值得业已定型的动态链接库共享时采用.前两种方法还有一个特点,即最后一条命令都是ldconfig,也即均需要更新一下缓存文件,以确保动态链接库的共享生效.

四、含有动态函数的程序的编译

4.1 防止编译因未指定动态链接库而出错

当一个程序使用动态函数时,编译该程序时就必须指定含所用动态函数的动态链接库,否则编译将会出错退出.如本文示例程序ady.c的编译(未明确引用动态链接库libmy.so):

# cc -o ady ady.c
/tmp/ccL4FsJp.o: In function `main':
/tmp/ccL4FsJp.o(.text+0x43): undefined reference to `gettime'
collect2: ld returned 1 exit status
#

注: 因为ady.c所含的动态函数getdate,gettime不在系统函数库中,所以连接时出错.

4.2 编译时引用动态链接库的几种方式

(1)当所用的动态链接库在系统目录(/lib,/usr/lib)下时,可用编译选项-l来引用.即:

# cc -lmy -o ady ady.c
#

注:编译时用-l选项引用动态链接库时,库名须使用其缩写形式.本例的my,表示引用libmy.so库.若引用光标库libncurses.so,须用-lncurses.注意,-l选项与参数之间不能有空格,否则会出错.

(2)当所用的动态链接库在系统目录(/lib,/usr/lib)以外的目录时,须用编译选项-L来指定动态链接库所在的目录(供编译器查找用),同时用-l选项指定缩写的动态链接库名.即:

# cc -L/usr/zzz/lib -lmy -o ady ady.c
#

(3)直接引用所需的动态链接库.即:

# cc -o ady ady.c libmy.so
#

或

# cc -o ady ady.c /lib/libmy.so
#

等等.其中,动态链接库的库名可以采用相对路径形式(文件名不以/开头),也可采用绝对路径形式(文件名以/开头).

五、动态链接程序的运行与检查

5.1 运行

编译连接好含动态函数的程序后,就可以运行它了.动态链接程序因为共享了系统中的动态链接库,所以其空间占用很小.但这并不意味功能的减少,它的执行与静态连接的程序执行,效果完全相同.在命令提示符下键入程序名及相关参数后回车即可,如下例:

$ ady
动态链接库高级应用示范
当前日期: 2002-03-11
当前时间: 19:39:06
$

5.2 检查

检查什么?检查动态链接程序究竟需要哪些共享库,系统中是否已有这些库,没有的话,用户好想办法把这些库装上.

怎么检查呢?这里,告诉你一个实用程序--ldd,这个程序就是专门用来检查动态链接程序依赖哪些共享库的.

ldd命令行用法如下:

ldd [--version] [-v|--verbose] [-d|--data-relocs] [-r|--function-relocs] [--help] FILE...

各选项说明如下:

(1) --version : 此选项用于打印出ldd的版本号.

(2) -v 或 --verbose : 此选项指示ldd输出关于所依赖的动态链接库的尽可能详细的信息.

(3) -d 或 --data-relocs : 此选项执行重定位,并且显示不存在的函数.

(4) -r 或 --function-relocs : 此选项执行数据对象与函数的重定位,同时报告不存在的对象.

(5) --help : 此选项用于打印出ldd的帮助信息.

注: 上述选项中,常用-v(或--verbose)选项.

ldd的命令行参数为FILE...,即一个或多个文件名(动态链接程序或动态链接库).

例1:

$ ldd ady
libmy.so => ./libmy.so (0x40026000)
libc.so.6 => /lib/libc.so.6 (0x40028000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$

注: 每行=>前面的,为动态链接程序所需的动态链接库的名字,而=>后面的,则是运行时系统实际调用的动态链接库的名字,所需的动态链接库在系统中不存在时,=>后面将显示"not found",括号所括的数字为虚拟的执行地址.本例列出ady所需的三个动态链接库,其中libmy.so为自己新建的动态链接库,而libc.so.6与/lib/ld-linux.so.2均为系统的动态链接库,前一个为基本C库,后一个动态装入库(用于动态链接库的装入及运行).

例2:

$ ldd -v ady
libmy.so => ./libmy.so (0x40026000)
libc.so.6 => /lib/libc.so.6 (0x40028000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Version information:
./ady:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
./libmy.so:
libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux.so.2 (GLIBC_2.1.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.2) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2
$

注:本例用-v选项以显示尽可能多的信息,所以例中除列出ady所需要的动态链接库外,还列出了程序所需动态链接库版本方面的信息.

小结: 在LINUX动态链接库的高级应用中,关键有两点,一是如何让动态链接库为LINUX系统所共享,二是编译连接程序时如何做.让动态链接库为系统所共享,主要是用ldconfig管理命令,维护好系统共享库的缓存文件/etc/ld.so.cache.编译连接时如何做?注意连接上所用的动态链接库就可以了.LINUX动态链接库的高级应用,用一用就明白:其实,就是这么简单!

[1 楼] | Posted: 2005-08-24 10:35

ppking

级别: 论坛版主
精华: 1
发帖: 28
威望: 65 点
金钱: 136 RMB
贡献值: 0 点
注册时间:2005-08-16
最后登录:2005-08-26

********几种不同UNIX系统常用的动态连接库建立的参数说明*****

创建共享库和链接可执行文件类似：首先把源代码编译成目标文件， 然后把目标文件链接起来．目标文件需要创建成 位置无关码（position-independent code） （PIC），概念上就是在可执行程序装载它们的时候， 它们可以放在可执行程序的内存里的任何地方， （用于可执行文件的目标文件通常不是用这个方式编译的．） 链接动态库的命令包含特殊标志，与链接可执行文件的命令是有区别的． --- 至少理论上如此．在一些系统里的现实更恶心．

在下面的例子里，我们假设你的源程序代码在 foo.c 文件里并且将创建成名字叫 foo.so的共享库．中介的对象文件将叫做 foo.o，除非我们另外注明．一个共享库可以 包含多个对象文件，不过我们在这里只用一个．

BSD/OS
创建 PIC 的编译器标志是 -fpic．创建共享库的链接器标志是 -shared．

gcc -fpic -c foo.c
ld -shared -o foo.so foo.o
上面方法适用于版本 4.0 的 BSD/OS．

FreeBSD
创建 PIC 的编译器标志是 -fpic．创建共享库的链接器标志是 -shared．

gcc -fpic -c foo.c
gcc -shared -o foo.so foo.o
上面方法适用于版本 3.0 的 FreeBSD.

HP-UX
创建 PIC 的系统编译器标志是 +z．如果使用 GCC 则是 -fpic． 创建共享库的链接器标志是 -b．因此

cc +z -c foo.c
或

gcc -fpic -c foo.c
然后

ld -b -o foo.sl foo.o
HP-UX 使用 .sl 做共享库扩展，和其它大部分系统不同．

IRIX
PIC 是缺省，不需要使用特殊的编译器选项． 生成共享库的链接器选项是 -shared.

cc -c foo.c
ld -shared -o foo.so foo.o

Linux
创建 PIC 的编译器标志是 -fpic．在一些平台上的一些环境下， 如果 -fpic 不能用那么必须使用-fPIC． 参考 GCC 的手册获取更多信息． 创建共享库的编译器标志是 -shared．一个完整的例子看起来象：

cc -fpic -c foo.c
cc -shared -o foo.so foo.o

NetBSD
创建 PIC 的编译器标志是 -fpic．对于 ELF 系统， 带 -shared 标志的编译命令用于链接共享库． 在老的非 ELF 系统里，使用ld -Bshareable．

gcc -fpic -c foo.c
gcc -shared -o foo.so foo.o

OpenBSD
创建 PIC 的编译器标志是 -fpic. ld -Bshareable 用于链接共享库．

gcc -fpic -c foo.c
ld -Bshareable -o foo.so foo.o

Solaris
创建 PIC 的编译器命令是用 Sun 编译器时为 -KPIC 而用 GCC 时为 -fpic．链接共享库时两个编译器都可以用 -G 或者用 GCC 时还可以是 -shared．

cc -KPIC -c foo.c
cc -G -o foo.so foo.o
或

gcc -fpic -c foo.c
gcc -G -o foo.so foo.o

Tru64 UNIX
PIC 是缺省，因此编译命令就是平常的那个． 带特殊选项的 ld 用于链接：

cc -c foo.c
ld -shared -expect_unresolved '*' -o foo.so foo.o
用 GCC 代替系统编译器时的过程是一样的；不需要特殊的选项．

UnixWare
SCO 编译器创建 PIC 的标志是-KPIC GCC 是 -fpic． 链接共享库时 SCO 编译器用 -G 而 GCC 用-shared．

cc -K PIC -c foo.c
cc -G -o foo.so foo.o
or

gcc -fpic -c foo.c
gcc -shared -o foo.so foo.o

技巧: 如果你想把你的扩展模块打包，用在更广的发布中，那么你应该考虑使用 GNU Libtool 制作共享库．它把平台之间的区别封装成 了一个通用的并且非常强大的接口．严肃的包还要求考虑有关库版本， 符号解析方法和一些其他的问题．

生成的共享库文件然后就可以装载到 PostgreSQL里面去了．在给 CREATE FUNCTION 命令声明文件名的时候，我们必须声明 共享库文件的名字而不是中间目标文件的名字．请注意你可以在 CREATE FUNCTION 命令上忽略 系统标准的共享库扩展 (通常是.so或.sl)， 并且出于最佳的兼容性考虑也应该忽略．

[2 楼] | Posted: 2005-08-24 10:36

ppking

级别: 论坛版主
精华: 1
发帖: 28
威望: 65 点
金钱: 136 RMB
贡献值: 0 点
注册时间:2005-08-16
最后登录:2005-08-26

源程序的显示和搜索

程序出错一般来说不只是出错的那条语句本身造成的。事实上出现错误经常是前面或相关的代码执行了不正确的操作或少了某
些必要的处理。因此调试过程中经常要观察一下源程序中的语句，或者在程序中搜索某个符号出现在什么地方。其中字符串的
搜索功能同vi基本上是相同的，而文件的显示则同另外一个我们没有具体讨论的编辑器ed类似。下面我们将具体介绍这些命令。

1.源程序的显示

在用core进入sdb之后，在*提示符后输入w命令，该命令指示sdb显示源程序中的当前行为中心的前后10行的内容并保持当前行
不变：

* w

7：int

8: TestInput(char * ValueInput)

9: {while ( * ValueInput)

10: if (! isdigit( * ValueInput)) return (! TESTOK);

11: else ValueInput++;

12: return ((100/atoi(ValueInput))? TESTOK:! TESTOK);

13: }

*

我们看到，在进入sdb时，当前行是第12行，以该行为中心的10行内容正好就是上面所显示出来的。其他可以显示源程序语
句的sdb命令如下：

P 显示当前行
l 显示对应于当前指令的那条语句
Z 显示当前行开始的下面10条语句
Ctrl+D 显示当前行之后（不包括当前行）的第10条语句
n 显示第n条语句，这里n是一个数
注意这些命令显示出的是源程序语句还是汇编语句（后面我们将要介绍)取决于最近一次显示出的是什么。

2.改变当前行

在用户显示语句时，当前行也会相应地发生变化。例如，Z命令将使当前行向程序尾移动9行，而Ctrl+D则使当前行向后移
动10行。

在使用数字来显示某行语句时将使该行语句成为当前行。而在*提示符之后按一下回车，当前行将下移一行。例如，接着上面
的例子，输入：

* 8p

8: TEstInput(char * ValueInput)

* 回车

9： { while ( * ValueInput)}

*

这里8p实际上是两条命令的组合。它使当前行移至源文件的第八行，然后再显示出新的当前行。按回车键将使当前行后移一行。

3.改变当前源文件

在vi中我们可以用e命令对另外某个文件进行编辑。sdb也提供了e命令，可以用此命令来改变当前文件，如：

* e myprog.c

current file is now myprog.c

* 8p

8: main(int argc,char * argv[])

*

我们看到，当前文件改变之后，sdb将第一行设为是当前行。如果此文件的第一行是个函数，那么该函数便成为当前函数。
否则将临时出现没有当前函数的情况。

在上一节中，我们介绍过在命令行中可以指定源文件搜索目录名列表（缺省情况为当前目录）。如果某个文件不在此搜索
目录中，则可以用e命令将其加入：

* e Another SourceDir

这里Another SourceDir是一个目录名。如果要显示该目录下的某个文件，只需要输入：

* e FileName.c

当然直接使用：

* e Another SourceDir/FileName.c

也能达到同样的效果。

使用：

* e FunctionName

将使包含函数FunctionName的文件名成为当前文件，而当前函数不言而喻将成为FunctionName。当前行则理所当然的是该
函数的第一行。同一程序中函数名在各模块中的唯一性保证了这一点是能够成功的，但如果包含指定函数的文件不在当前
搜索目录列表中，则必须用e命令将其加入。

4.字符串的搜索

在vi中，我们可以在命令方式下使用“/“或者“？”命令，从当前位置向后或者向前搜索某个字符串，在sdb中也同样可
以完成这一点。使用这两个命令我们可以查找源程序中某个或某类符号的出现。之所以说某类，是因为我们可以用正规表
达式来指定待搜索的串（也即在搜索串中可以使用*,?,[,],-,^这类特殊字符）。

例如，为了查找myprog.c中argv出现在那些行上，可输入：

* /argv/

8: main(ini argc,char * argv[])

sdb将从当前行开始向文件尾搜索，到达文件尾之后又从文件头开始直至搜索到某个匹配的串或到达当前行为止。

与/相反，？命令将从当前行向文件头方向搜索，因此如果我们将上述/argv/换成：

* ? argv?

14: printf("The %dth value' %s'tis BAD! n",i,argv);

*

所得的结果一般是不同的。

/或?命令之后的/或?并不是必须的。另外如果要在同一方向上继续搜索上次搜索过的串，只需要直接输入/或者?即可。

[3 楼] | Posted: 2005-08-24 10:38

ppking

级别: 论坛版主
精华: 1
发帖: 28
威望: 65 点
金钱: 136 RMB
贡献值: 0 点
注册时间:2005-08-16
最后登录:2005-08-26

***************ld是怎么连接的**********************

由於静态与共享程式库两者间不相容的格式的差异性与动词*link*过量使用於指称*编译完成後的事情*与*当编译好的程式使用时所发生的事情*这两件事上头，使得这一章节变得复杂了许多。（ and, actually, the overloading of the word `load' in a comparable but opposite sense）不过，再复杂也就是这样了，所以阁下不必过於担心。

为了稍微减轻读者的困惑，我们称执行期间所发生的事为*动态载入*，这一主题会在下一章节中谈到。你也会在别的地方看到我把动态载入描述成*动态连结*，不过不会是在这一章节中。换句话说，这一章节所谈的，全部是指发生在编译结束後的连结。

6.1 共享程式库 vs静态程式库

建立程式的最後一个步骤便是连结；也就是将所有分散的小程式组合起来，看看是否遗漏了些什麽。显然，有一些事情是很多程式都会想做的---例如，开启档案，接著所有与开档有关的小程式就会将储存程式库的相关档案提供给你的程式使用。在一般的Linux系统上，这些小程式可以在/lib与/usr/lib/目录底下找到。

当你用的是静态的程式库时，连结器会找出程式所需的模组，然後实际将它们拷贝到执行档内。然而，对共享程式库而言，就不是这样了。共享程式库会在执行档内留下一个记号，指明*当程式执行时，首先必须载入这个程式库*。显然，共享程式库是试图使执行档变得更小，等同於使用更少的记忆体与磁碟空间。Linux内定的行为是连结共享程式库，只要Linux能找到这些共享程式库的话，就没什麽问题；不然,Linux就会连结静态的了。如果你想要共享程式库的话，检查这些程式库（*.sa for a.out, *.so for ELF）是否住在它们该在的地方，而且是可读取的。

在Linux上，静态程式库会有类似libname.a这样的名称；而共享程式库则称为libname.so.x.y.z，此处的x.y.z是指版本序号的样式。共享程式库通常都会有连结符号指向静态程式库（很重要的）与相关联的.sa档案。标准的程式库会包含共享与静态程式库两种格式。

你可以用ldd（List Dynamic Dependencies）来查出某支程式需要哪些共享程式库。 $ ldd /usr/bin/lynx libncurses.so.1 => /usr/lib/libncurses.so.1.9.6 libc.so.5 => /lib/libc.so.5.2.18

这是说在我的系统上，WWW浏览器*lynx*会依赖libc.so.5 (the C library)与libncurses.so.1（终端机萤幕的控制）的存在。若某支程式缺乏独立性， ldd就会说‘statically linked’或是‘statically linked (ELF)’。

6.2 终极审判（‘sin() 在哪个程式库里？’）

nm 程式库名称应该会列出此程式库名称所参考到的所有符号。这个指令可以应用在静态与共享程式库上。假设你想知道tcgetattr()是在哪儿定义的：你可以如此做，

$ nm libncurses.so.1 |grep tcget U tcgetattr

*U*指出*未定义*---也就是说ncurses程式库有用到tegetattr()，但是并没有定义它。你也可以这样做，

$ nm libc.so.5 | grep tcget 00010fe8 T __tcgetattr 00010fe8 W tcgetattr 00068718 T tcgetpgrp

*W*说明了*弱态(weak)*，意指符号虽已定义，但可由不同程式库中的另一定义所替代。最简单的*正常*定义（像是tcgetpgrp）是由*T*所标示：

标题所谈的问题，最简明的答案便是libm.(so|a)了。所有定义在<math.h>的函数都保留在maths程式库内；因此，当你用到其中任何一个函数时，都需要以-lm的参数连结此程式库。

6.3 X档案？

ld: Output file requires shared library `libfoo.so.1`

ld与其相类似的命令在搜寻档案的策略上，会依据版本的差异而有所不同，但是唯一一个你可以合理假设的内定目录便是/usr/lib了。如果你希望身处它处的程式库也列入搜寻的行列中，那麽你就必须以-L选项告知gcc或是ld。

要是你发现一点效果也没有，就赶紧察看看那档案是不是还乖乖的躺在原地。就a.out而言，以-lfoo参数来连结，会驱使ld去寻找libfoo.sa（shared stubs）；如果没有成功，就会换成寻找libfoo.a（static）。就ELF而言， ld会先找libfoo.so，然後是libfoo.a。libfoo.so通常是一个连结符号，连结至libfoo.so.x。

6.4 建立你自己的程式库 控制版本

与其它任何的程式一样，程式库也有修正不完的bugs的问题存在。它们也可能产生出一些新的特点，更改目前存在的模组的功效，或是将旧的移除掉。这对正在使用它们的程式而言，可能会是一个大问题。如果有一支程式是根据那些旧的特点来执行的话，那怎麽办？

所以，我们引进了程式库版本编号的观念。我们将程式库*次要*与*主要*的变更分门别类，同时规定*次要*的变更是不允许用到这程式库的旧程式发生中断的现象。你可以从程式库的档名分辨出它的版本（实际上，严格来讲，对ELF而言仅仅是一场天大的谎言；继续读将下去，便可明白为什麽了）： libfoo.so.1.2的主要版本是1，次要版本是2。次要版本的编号可能真有其事，也可能什麽都没有---libc在这一点上用了*修正程度*的观念，而订出了像libc.so.5.2.18这样的程式库名称。次要版本的编号内若是放一些字母、底线、或是任何可以列印的ASCII字元，也是很合理的。

ELF与a.out格式最主要的差别之一就是在设置共享程式库这件事上；我们先看ELF，因为它比较简单一些。

ELF？它到底是什麽东东ㄋㄟ？

ELF（Executable and Linking Format）最初是由USL（UNIX System Laboratories）发展而成的二进位格式，目前正应用於Solaris与System V Release 4上。由於ELF所增涨的弹性远远超过Linux过去所用的a.out格式，因此GCC与C程式库的发展人士於1995年决定改用ELF为Linux标准的二进位格式。

怎麽又来了？

这一节是来自於‘/news-archives/comp.sys.sun.misc’的文件。

ELF（“Executable Linking Format”）是於SVR4所引进的新式改良目的档格式。ELF比起COFF可是多出了不少的功能。以ELF而言，它*是*可由使用者自行延伸的。ELF视一目的档为节区（sections），如串列般的组合；而且此串列可为任意的长度（而不是一固定大小的阵列）。这些节区与COFF的不一样，并不需要固定在某个地方，也不需要以某种顺序排列。如果使用者希望补捉到新的资料，便可以加入新的节区到目的档内。ELF也有一个更强而有力的除错法式，称为DWARF（Debugging With Attribute Record Format）□目前Linux并不完全支援。DWARF DIEs（Debugging Information Entries）的连结串列会在ELF内形成 .debug的节区。DWARF DIEs的每一个 .debug节区并非一些少量且固定大小的资讯记录的集合，而是一任意长度的串列，拥有复杂的属性，而且程式的资料会以有□围限制的树状资料结构写出来。DIEs所能补捉到的大量资讯是COFF的 .debug节区无法望其项背的。（像是C++的继承图。）

ELF档案是从SVR4（Solaris 2.0 ？）ELF存取程式库（ELF access library）内存取的。此程式库可提供一简便快速的介面予ELF。使用ELF存取程式库最主要的恩惠之一便是，你不再需要去察看一个ELF档的qua了。就UNIX的档案而言，它是以Elf*的型式来存取；呼叫elf_open()之後，从此时开始，你只需呼叫elf_foobar()来处理档案的某一部份即可，并不需要把档案实际在磁碟上的image搞得一团乱。

ELF的优缺点与升级至ELF等级所需经历的种种痛苦，已在ELF-HOWTO内论及；我并不打算在这儿涂浆糊。ELF HOWTO应该与这份文件有同样的主题才是。

ELF共享程式库

若想让libfoo.so成为共享程式库，基本的步骤会像下面这样：

$ gcc -fPIC -c *.c $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o $ ln -s libfoo.so.1.0 libfoo.so.1 $ ln -s libfoo.so.1 libfoo.so $ LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ; export LD_LIBRARY_PATH

这会产生一个名为libfoo.so.1.0的共享程式库，以及给予ld适当的连结（libfoo.so）还有使得动态载入程式（dynamic loader）能找到它（libfoo.so.1）。为了进行测试，我们将目前的目录加到LD_LIBRARY_PATH里。

当你津津乐道於程式库制做成功之时，别忘了把它移到如/usr/local/lib的目录底下，并且重新设定正确的连结路径。libfoo.so.1与libfoo.so.1.0的连结会由ldconfig依日期不断的更新，就大部份的系统来说，ldconfig会在开机过程中执行。libfoo.so的连结必须由手动方式更新。如果你对程式库所有组成份子（如标头档等）的升级，总是抱持著一丝不□的态度，那麽最简单的方法就是让libfoo.so -> libfoo.so.1；如此一来，ldconfig便会替你同时保留最新的连结。要是你没有这麽做，你自行设定的东东就会在数日後造成千奇百怪的问题出现。到时候，可别说我没提醒你啊！

$ su # cp libfoo.so.1.0 /usr/local/lib # /sbin/ldconfig # ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so

版本编号、soname与符号连结

每一个程式库都有一个soname。当连结器发现它正在搜寻的程式库中有这样的一个名称，连结器便会将soname箝入连结中的二进位档内，而不是它正在运作的实际的档名。在程式执行期间，动态载入程式会搜寻拥有soname这样的档名的档案，而不是程式库的档名。因此，一个名为libfoo.so的程式库，就可以有一个libbar.so的soname了。而且所有连结到libbar.so的程式，当程式开始执行时，会寻找的便是libbar.so了。

这听起来好像一点意义也没有，但是这一点，对於了解数个不同版本的同一个程式库是如何在单一系统上共存的原因，却是关键之钥。Linux程式库标准的命名方式，比如说是libfoo.so.1.2，而且给这个程式库一个libfoo.so.1的soname。如果此程式库是加到标准程式库的目录底下（e.g. /usr/lib），ldconfig会建立符号连结libfoo.so.1 -> libfoo.so.1.2，使其正确的image能於执行期间找到。你也需要连结libfoo.so -> libfoo.so.1，使ld能於连结期间找到正确的soname。

所以罗，当你修正程式库内的bugs，或是添加了新的函数进去（任何不会对现存的程式造成不利的影响的改变），你会重建此程式库，保留原本已有的soname，然後更改程式库档名。当你对程式库的变更会使得现有的程式中断，那麽你只需增加soname中的编号---此例中，称新版本为libfoo.so.2.0，而soname变成libfoo.so.2。紧接著，再将libfoo.so的连结转向新的版本；至此，世界又再度恢复了和平！

其实你不须要以此种方式来替程式库命名，不过这的确是个好的传统。ELF赋予你在程式库命名上的弹性，会使得人气喘呼呼的搞不清楚状况；有这样的弹性在，也并不表示你就得去用它。

ELF总结：假设经由你睿智的观察发现有个惯例说：程式库主要的升级会破坏相容性；而次要的升级则可能不会；那麽以下面的方式来连结，所有的一切就都会相安无事了。

gcc -shared -Wl,-soname,libfoo.so.major -o libfoo.so.major.minor

a.out---旧旧的格式□

建立共享程式库的便利性是升级至ELF的主要原因之一。那也是说,a.out可能还是有用处在的。上ftp站去抓 ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.17.tar.gz；解压缩後你会发现有20页的文件可以慢慢的读哩。我很不喜欢自己党派的偏见表现得那麽的淋璃尽致，可是从上下文间，应该也可以很清楚的嗅出我从来不拿石头砸自己的脚的脾气吧！

ZMAGIC vs QMAGIC

QMAGIC是一种类似旧格式的a.out（亦称为ZMAGIC）的可执行档 格式，这种格式会使得第一个分页无法map。当0-4096的□围内没有mapping存在时，则可允许NULL dereference trapping更加的容易。所产生的边界效应是你的执行档会比较小（大约少1K左右）。

只有即将作废的连结器有支援ZMAGIC，一半已埋入棺材的连结器有支援这两种格式；而目前的版本仅支援QMAGIC而已。事实上，这并没有多大的影响，那是因为目前的核心两种格式都能执行。

*file*命令应该可以确认程式是不是QMAGIC的格式的。

档案配置

一a.out(DLL)的共享程式库包含两个真实的档案与一个连结符号。就*foo*这个用於整份文件做为□例的程式库而言，这些档案会是libfoo.sa与libfoo.so.1.2；连结符号会是libfoo.so.1，而且会指向libfoo.so.1.2。这些是做什麽用的？

在编译时，ld会寻找libfoo.sa。这是程式库的*stub*档案。而且含有所有执行期间连结所需的exported的资料与指向函数的指标。

执行期间，动态载入程式会寻找libfoo.so.1。这仅仅是一个符号连结，而不是真实的档案。故程式库可更新成较新的且已修正错误的版本，而不会损毁任何此时正在使用此程式库的应用程式。在新版---比如说libfoo.so.1.3---已完整呈现时，ldconfig会以一极微小的操作，将连结指向新的版本，使得任何原本使用旧版的程式不会感到丝毫的不悦。

DLL程式库（我知道这是无谓的反覆---所以对我提出诉讼吧！）通常会比它们的静态副本要来得大多。它们是以*洞（holes）*的形式来保留空间以便日後的扩充。这种*洞*可以不占用任何的磁碟空间。一个简单的cp呼叫，或是使用makehole程式，就可以达到这样效果。因为它们的位址是固定在同一位置上，所以在建立程式库後，你可以把它们拿掉。不过，千万不要试著拿掉ELF的程式库。

**********************动态载入过程***************

Linux有共享程式库，如果之前你已坐著读完上一章节，想必现在一听到像这样的说词，便会立刻感到头昏。有一些照惯例而言是在连结时期便该完成的工作，必须延迟到载入时期才能完成。 7.2 错误讯息

把你连结的错误寄给我！我不会做任何的事，不过我可以把它们写起来**

can't load library: /lib/libxxx.so, Incompatible version

（a. out only） 这是指你没有xxx程式库的正确的主要版本。可别以为随随 便便弄个连结到你目前拥有的版本就可以了，如果幸运的话，就只会造成你的程式分页错误而已。去抓新的版本.ELF类似的情况会造成像下面这样的讯息：

ftp: can't load library 'libreadline.so.2'

warning using incompatible library version xxx

（a. out only）你的程式库的次要版本比起这支程式用来编译的还要旧。程式依然可以执行。只是可能啦！我想，升个级应该没什麽伤害吧！

7.3 控制动态载入器的运作

有一组环境变数会让动态载入器有所反应。大部份的环境变数对ldd的用途要比起对一般users的还要来得更多。而且可以很方便的设定成由ldd配合各种参数来执行。这些变数包括，

LD_BIND_NOW --- 正常来讲，函数在呼叫之前是不会让程式寻找的。设定这个旗号会使得程式库一载入，所有的寻找便会发生，同时也造成起始的时间较慢。当你想测试程式，确定所有的连结都没有问题时，这项旗号就变得很有用。 LD_PRELOAD可以设定一个档案，使其具有*覆盖*函数定义的能力。例如，如果你要测试记忆体分配的方略，而且还想置换*malloc*，那麽你可以写好准备替换的副程式，并把它编译成mallolc.，然後： $ LD_PRELOAD=malloc.o; export LD_PRELOAD $ some_test_program LD_ELF_PRELOAD 与 LD_AOUT_PRELOAD 很类似，但是仅适用於正确的二进位型态。如果设定了 LD_something_PRELOAD 与 LD_PRELOAD ，比较明确的那一个会被用到。 LD_LIBRARY_PATH是一连串以分号隔离的目录名称，用来搜寻共享程式库。对ld而言，并没有任何的影响；这项只有在执行期间才有影响。另外，对执行setuid与setgid的程式而言，这一项是无效的。而LD_ELF_LIBRARY_PATH与LD_AOUT_LIBRARY_PATH这两种旗号可根据各别的二进位型式分别导向不同的搜寻路径。一般正常的运作下，不应该会用到LD_LIBRARY_PATH；把需要搜寻的目录加到/etc/ld.so.conf/里；然後重新执行ldconfig。 LD_NOWARN 仅适用於a.out。一旦设定了这一项（LD_NOWARN=true; export LD_NOWARN），它会告诉载入器必须处理fatal-warnings（像是次要版本不相容等）的警告讯息。 LD_WARN仅适用於ELF。设定这一项时，它会将通常是致命讯息的“Can*t find library”转换成警告讯息。对正常的操作而言，这并没有多大的用处，可是对ldd就很重要了。 LD_TRACE_LOADED_OBJECTS仅适用於ELF。而且会使得程式以为它们是由ldd所执行的： $ LD_TRACE_LOADED_OBJECTS=true /usr/bin/lynx libncurses.so.1 => /usr/lib/libncurses.so.1.9.6 libc.so.5 => /lib/libc.so.5.2.18

7.4 以动态载入撰写程式

如果你很熟悉Solaris 2.x所支援的动态载入的工作的话，你会发现Linux在这点上与其非常的相近。这一部份在H.J.Lu的ELF程式设计文件内与dlopen(3)的manual page（可以在ld.so的套件上找到）上有广泛的讨论

http://blog.sina.com.cn/u/48221e89010002ol

在小乌的眼里，库文件就是资源文件，也没有什么难以理解的；可是如果真要问得深入一点：“动态链接库和静态链接库有什么区别？”，“怎么做一个动态链接库？”，“怎么生成静态/动态链接库？”，“什么叫显示/隐示调用？”。。。小乌就郁闷了，所以今天决定要拍死这些问题。
Window下面的动/静态链接库文件名分别为：.dll和.lib；
Linux下则为：.so或.so.x和.a；.so文件的标准形式应该为：libxxx.so或libxxx.so.y，前缀的lib是为了系统能识别它，后缀的.y则是版本号，可有可无；静态链接库对于linux来说叫共享库或许来的比较标准，静态库文件.a则可以看做是目标文件.o的一个集合，形式也必须为libxxx.a。
.lib对.a，.dll对.so。或许从名字及应用的OS来看，没什么太大的联系，但实际上都是换汤不换药，一个故事，所以在这里拿到一起来说。依小乌之见，所有的库文件实际上都是资源文件，也就是说，作为“备选的资源”而存在，只将必要的部分导入到自己的程序中；但是区别是：静态库必要的目标代码的是在对程序编译的时候被加入到程序中，而动态库的目标代码是在被调用的时候加入到程序中，所以相比之下动态库更加灵活，也没有象静态库那样存在对系统资源浪费的问题。但是静态库是不是就没有他存在的意义呢？不见得，有人举了这么一个例子：如果你用libpcap库编了一个程序，要给被人运行，而他的系统上没有装pcap库，该怎么解决呢？最简单的办法就是编译该程序时把所有要链接的库都链接它们的静态库，这样，就可以在别人的系统上直接运行该程序了。虽然现在小乌还没有完全理解。。。但是，存在即合理。
在Windows系统下的执行文件格式是PE格式，动态库需要一个DllMain函数作为初始化的人口，通常在导出函数的声明时需要有_declspec(dllexport)关键字。Linux下的gcc编译的执行文件默认是ELF格式，不需要初始化入口，亦不需要到函数做特别声明，编写比较方便。
说说linux下生成动/静态链接库,下面是小乌的一个Makefile文件：
#makefile for libmy.so
libwuxian.so : getdate.o gettime.o
gcc -shared -o libwuxian.so getdate.o gettime.o
rm -f *.o
getdate.o : datetime.h
gcc -c getdate.c
gettime.o : datetime.h
gcc -c gettime.c
别被弄蒙了，这是小乌拿来练习的Makefile文件。最重要的一句话gcc -shared -o libwuxian.so getdate.o gettime.o,在shell下其实也就一句话：gcc -shared -o libwuxian.so getdate.c gettime.c,-shared说明生成的是动态链接库，-o后面接生成的动态链接库文件名，必须以lib打头，.so或者.so.x结尾，x为版本号。关于Makefile文件的写法，请看：Makefile的傻瓜写法。
对于静态库，则应该如下：
gcc -c xx.c
gcc -c ll.c
ar cqs libwx.a xx.o ll.o 或者ar r libwx.a xx.o ll.o
xx.c为源文件,xx.o为目标文件，ar cqs libwx.so xx.o ll.o是将目标文件xx.o及ll.o链接为libwx.so，静态库名必须以lib打头，.a结尾。

再说说动/静态链接库的使用。静态库是在编译时简单的将被用到的目标代码加入到可执行程序，所以我们先说它的使用：
# gcc -c main.c -o main.o
# gcc main.o -o qqq -L. -lwx
使用gcc编译，假设我们这里所有的文件都保存在同一个目录下,第一句是将main.c编译成目标文件，第二句则是将目标文件libwx.a和main.o链接到可执行程序中。

动态库的使用则分为显式调用和隐式调用，显式调用需要了解以下几个函数：
const char *dlerror(void);
当动态链接库操作函数执行失败时，dlerror可以返回出错信息，为NULL时表示操作函数执行成功。
void *dlopen (const char *filename, int flag);
成功则返回为void*的句柄。flag可以为RTLD_LAZY(表明在动态链接库的函数代码执行时解决);RTLD_NOW(表明在dlopen返回前就解决所有未定义的符号，一旦未解决，dlopen将返回错误)。filename为动态库路径。
void *dlsym(void *handle, char *symbol);
dlsym根据动态链接库操作句柄(handle)与符号（实际上就是欲调用的函数名），返回符号对应的函数的执行代码地址。由此地址，可以带参数执行相应的函数。
int dlclose (void *handle);
参数为动态链接库的句柄。
显式调用动态链接库必须包含动态链接库功能接口dlfcn.h（包含dl系列函数的声明）和被调函数的声明。看起来还比较简单，但是当你对动态链接库函数使用比较频繁的时候，你就知道他的麻烦了，所以，不推崇。

隐式调用。所谓隐式调用，就是调用的时候直接使用动态库中的函数，并不区别对待。但是在隐式调用的时候必须要让程序能找到你所调用的函数的所属动态库。我们先来建立一个感性认识：
# more /etc/ld.so.conf 你会看到以下内容：
/usr/kerberos/lib
/usr/X11R6/lib
/usr/lib/sane
/usr/lib/qt-3.1/lib
/usr/lib/mysql
/usr/lib/qt2/lib
/usr/local/lib
/usr/local/BerkeleyDB.4.3/lib
ld.so.conf是系统对动态链接库进行查找的路径配置文件，也就是说该文件是系统链接工具/usr/bin/ld查找动态链接库的地图，所以，要达到我们的目的有以下几种方法：
1. 将自己的动态链接库文件拷到以上路径的目录下。
# cp libwx.so.1 /usr/local/lib
2. 将自己动态链接库文件的路径加入到该文件中。
要么# vi /etc/ld.so.conf， 然后加入自己的路径
要么# pwd >>/etc/ld.so.conf
注意：千万不要将>>写成>，前者是添加，后者是覆盖，不相信你自己玩玩看。
3. 把当前路径加入环境变量LD_LIBRARY_PATH，其实就是/usr/bin/ld的环境变量。
# export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
编译的时候：
# gcc -o qqq main.c libmy.so.1
如果没有让/usr/bin/ld知道你的动态链接库在哪，编译的时候就要告诉它：
# gcc -o qqq main.c /root/wx/libmy.so.1
或者：# gcc -L/root/wx -o qqq main.c libmy.so.1
-L指定动态链接库所在的目录，有时候用gcc还会碰到-I，-l，他们分别指定头文件的目录和所链接的动态链接库。
另外说一个shell命令：
# ldd qqq
用来查看可执行文件qqq的动态链接库的依赖关系。

http://www.sinklow.com/fox/article.asp?id=22

创建共享库的过程如下所述：
１。编译目标文件时使用ＧＣＣ的 -fPIC选项，这能产生于位置无关的代码并能加载到任何地址。
２。使用ＧＣＣ的 -shared 和 -soname选项。
３。使用ＧＣＣ的-Wl选项把参数传递给链接器ｌｄ。　
４。使用ＧＣＣ的-l选项显示地链接Ｃ库，以保证可以得到所需的启动代码（startup）代码，从而避免程序在使用不同的，可能是
　　不兼容版本的Ｃ库的系统上不能启动执行。

<------Makefile----->
CC=gcc
CFLAGS = -g -O2 -Wall
LIB_NAME=libtest.so
LIB_VER=1.0.0
OBJS=test1.o test2.o
all:$(OBJS)
$(CC) $(CFLAGS) -shared -Wl,-soname,$(LIB_NAME) -o $(LIB_NAME).$(LIB_VER) $(OBJS) -lc
%.o: %.c
%(CC) $(CFLAGS) -fPIC -c $< -o $@
<------EOF--------->

gcc的预处理提供的可变参数宏定义真是好用：

int setjmp( jmp_buf env );

　　这是MSDN中对它的评论，如下：

　　setjmp函数用于保存程序的运行时的堆栈环境，接下来的其它地方，你可以通过调用longjmp函数来恢复先前被保存的程序堆栈环境。当 setjmp和longjmp组合一起使用时，它们能提供一种在程序中实现“非本地局部跳转”（"non-local goto"）的机制。并且这种机制常常被用于来实现，把程序的控制流传递到错误处理模块之中；或者程序中不采用正常的返回（return）语句，或函数的 正常调用等方法，而使程序能被恢复到先前的一个调用例程（也即函数）中。

　　对setjmp函数的调用时，会保存程序当前的堆栈环境到env参数中；接下来调用longjmp时，会根据这个曾经保存的变量来恢复先前的环 境，并且当前的程序控制流，会因此而返回到先前调用setjmp时的程序执行点。此时，在接下来的控制流的例程中，所能访问的所有的变量（除寄存器类型的 变量以外），包含了longjmp函数调用时，所拥有的变量。

　　setjmp和longjmp并不能很好地支持C++中面向对象的语义。因此在C++程序中，请使用C++提供的异常处理机制。

　　好了，现在已经对setjmp有了很感性的了解，暂且不做过多评论，接着往下看longjmp函数。

longjmp函数有何作用？

　　同样，longjmp也是C标准库中提供的一个函数，它的作用是用于恢复程序执行的堆栈环境，它的函数原型如下：

void longjmp( jmp_buf env, int value );

　　这是MSDN中对它的评论，如下：

　　longjmp函数用于恢复先前程序中调用的setjmp函数时所保存的堆栈环境。setjmp和longjmp组合一起使用时，它们能提供一 种在程序中实现“非本地局部跳转”（"non-local goto"）的机制。并且这种机制常常被用于来实现，把程序的控制流传递到错误处理模块，或者不采用正常的返回（return）语句，或函数的正常调用等 方法，使程序能被恢复到先前的一个调用例程（也即函数）中。

　　对setjmp函数的调用时，会保存程序当前的堆栈环境到env参数中；接下来调用longjmp时，会根据这个曾经保存的变量来恢复先前的环 境，并且因此当前的程序控制流，会返回到先前调用setjmp时的执行点。此时，value参数值会被setjmp函数所返回，程序继续得以执行。并且， 在接下来的控制流的例程中，它所能够访问到的所有的变量（除寄存器类型的变量以外），包含了longjmp函数调用时，所拥有的变量；而寄存器类型的变量 将不可预料。setjmp函数返回的值必须是非零值，如果longjmp传送的value参数值为0，那么实际上被setjmp返回的值是1。

　　在调用setjmp的函数返回之前，调用longjmp，否则结果不可预料。

　　在使用longjmp时，请遵守以下规则或限制：
　　· 不要假象寄存器类型的变量将总会保持不变。在调用longjmp之后，通过setjmp所返回的控制流中，例程中寄存器类型的变量将不会被恢复。
　　· 不要使用longjmp函数，来实现把控制流，从一个中断处理例程中传出，除非被捕获的异常是一个浮点数异常。在后一种情况下，如果程序通过调用_fpreset函数，来首先初始化浮点数包后，它是可以通过longjmp来实现从中断处理例程中返回。
　　· 在C++程序中，小心对setjmp和longjmp的使用，应为setjmp和longjmp并不能很好地支持C++中面向对象的语义。因此在C++程序中，使用C++提供的异常处理机制将会更加安全。
把setjmp和longjmp组合起来，原来它这么厉害！
　　现在已经对setjmp和longjmp都有了很感性的了解，接下来，看一个示例，并从这个示例展开分析，示例代码如下（来源于MSDN）：

/* FPRESET.C: This program uses signal to set up a
* routine for handling floating-point errors.
*/

＃i nclude <stdio.h>
＃i nclude <signal.h>
＃i nclude <setjmp.h>
＃i nclude <stdlib.h>
＃i nclude <float.h>
＃i nclude <math.h>
＃i nclude <string.h>

jmp_buf mark; /* Address for long jump to jump to */
int fperr; /* Global error number */

void __cdecl fphandler( int sig, int num ); /* Prototypes */
void fpcheck( void );

void main( void )
{
double n1, n2, r;
int jmpret;
/* Unmask all floating-point exceptions. */
_control87( 0, _MCW_EM );
/* Set up floating-point error handler. The compiler
* will generate a warning because it expects
* signal-handling functions to take only one argument.
*/
if( signal( SIGFPE, fphandler ) == SIG_ERR )

{
fprintf( stderr, "Couldn't set SIGFPEn" );
abort(); }

/* Save stack environment for return in case of error. First
* time through, jmpret is 0, so true conditional is executed.
* If an error occurs, jmpret will be set to -1 and false
* conditional will be executed.
*/

// 注意，下面这条语句的作用是，保存程序当前运行的状态
jmpret = setjmp( mark );
if( jmpret == 0 )
{
printf( "Test for invalid operation - " );
printf( "enter two numbers: " );
scanf( "%lf %lf", &n1, &n2 );

// 注意，下面这条语句可能出现异常，
// 如果从终端输入的第2个变量是0值的话
r = n1 / n2;
/* This won't be reached if error occurs. */
printf( "nn%4.3g / %4.3g = %4.3gn", n1, n2, r );

r = n1 * n2;
/* This won't be reached if error occurs. */
printf( "nn%4.3g * %4.3g = %4.3gn", n1, n2, r );
}
else
fpcheck();
}
/* fphandler handles SIGFPE (floating-point error) interrupt. Note
* that this prototype accepts two arguments and that the
* prototype for signal in the run-time library expects a signal
* handler to have only one argument.
*
* The second argument in this signal handler allows processing of
* _FPE_INVALID, _FPE_OVERFLOW, _FPE_UNDERFLOW, and
* _FPE_ZERODIVIDE, all of which are Microsoft-specific symbols
* that augment the information provided by SIGFPE. The compiler
* will generate a warning, which is harmless and expected.

*/
void fphandler( int sig, int num )
{
/* Set global for outside check since we don't want
* to do I/O in the handler.
*/
fperr = num;
/* Initialize floating-point package. */
_fpreset();
/* Restore calling environment and jump back to setjmp. Return
* -1 so that setjmp will return false for conditional test.
*/
// 注意，下面这条语句的作用是，恢复先前setjmp所保存的程序状态
longjmp( mark, -1 );
}
void fpcheck( void )
{
char fpstr[30];
switch( fperr )
{
case _FPE_INVALID:
strcpy( fpstr, "Invalid number" );
break;
case _FPE_OVERFLOW:
strcpy( fpstr, "Overflow" );

break;
case _FPE_UNDERFLOW:
strcpy( fpstr, "Underflow" );
break;
case _FPE_ZERODIVIDE:
strcpy( fpstr, "Divide by zero" );
break;
default:
strcpy( fpstr, "Other floating point error" );
break;
}
printf( "Error %d: %sn", fperr, fpstr );
}

程序的运行结果如下：
Test for invalid operation - enter two numbers: 1 2

1 / 2 = 0.5

1 * 2 = 2

　　上面的程序运行结果正常。另外程序的运行结果还有一种情况，如下：
Test for invalid operation - enter two numbers: 1 0
Error 131: Divide by zero

　　呵呵！程序运行过程中出现了异常（被0除），并且这种异常被程序预先定义的异常处理模块所捕获了。厉害吧！可千万别轻视，这可以C语言编写的程序。

分析setjmp和longjmp

　　现在，来分析上面的程序的执行过程。当然，这里主要分析在异常出现的情况下，程序运行的控制转移流程。由于文章篇幅有限，分析时，我们简化不相关的代码，这样更也易理解控制流的执行过程。如下图所示。

440){this.resized=true;this.style.width=440;}" style="cursor: pointer; width: 440px;" onclick="javascript:window.open(this.src);" src="http://bcbfans.shineblog.com/UploadFiles/2006-7/71772552.jpg" />

　　呵呵！现在是否对程序的执行流程一目了然，其中最关键的就是setjjmp和longjmp函数的调用处理。我们分别来分析之。

　 　当程序运行到第②步时，调用setjmp函数，这个函数会保存程序当前运行的一些状态信息，主要是一些系统寄存器的值，如ss，cs，eip，eax， ebx，ecx，edx，eflags等寄存器，其中尤其重要的是eip的值，因为它相当于保存了一个程序运行的执行点。这些信息被保存到mark变量 中，这是一个C标准库中所定义的特殊结构体类型的变量。

　　调用setjmp函数保存程序状态之后，该函数返回0值，于是接下来程序执行到第③步和第④步中。在第④步中语句执行时，如果变量n2为0值，于是便引发了一个浮点数计算异常，，导致控制流转入fphandler函数中，也即进入到第⑤步。

　 　然后运行到第⑥步，调用longjmp函数，这个函数内部会从先前的setjmp所保存的程序状态，也即mark变量中，来恢复到以前的系统寄存器的 值。于是便进入到了第⑦步，注意，这非常有点意思，实际上，通过longjmp函数的调用后，程序控制流（尤其是eip的值）再次戏剧性地进入到了 setjmp函数的处理内部中，但是这一次setjmp返回的值是longjmp函数调用时，所传入的第2个参数，也即-1，因此程序接下来进入到了第⑧ 步的执行之中。

总结

　　与goto语句不同，在C语言中，setjmp()与longjmp()的组合调用，为程序员提供了一种更优雅的异常处理机制。它具有如下特点：

　　 （1） goto只能实现本地跳转，而setjmp()与longjmp()的组合运用，能有效的实现程序控制流的非本地（远程）跳转；

　 　 （2） 与goto语句不同，setjmp()与longjmp()的组合运用，提供了真正意义上的异常处理机制。例如，它能有效定义受监控保护的模块区域（类似 于C++中try关键字所定义的区域）；同时它也能有效地定义异常处理模块（类似于C++中catch关键字所定义的区域）；还有，它能在程序执行过程 中，通过longjmp函数的调用，方便地抛出异常（类似于C++中throw关键字）。

　　现在，相信大家已经对在C语言中提供的这种异常处理机制有了很全面地了解。但是我们还没有深入它研究它，下一篇文章中继续探讨吧！go！

上一篇文章对setjmp函数与longjmp函数有了较全面的了解，尤其是这两个函数的作用，函数所完成的功能，以及将setjmp函数与 longjmp函数组合起来，实现异常处理机制时，程序模块控制流的执行过程等。这里更深入一步，将对setjmp与longjmp的具体使用方法和适用 的场合，进行一个非常全面的阐述。

　　另外请特别注意，setjmp函数与longjmp函数总是组合起来使用，它们是紧密相关的一对操作，只有将它们结合起来使用，才能达到程序控制流有效转移的目的，才能按照程序员的预先设计的意图，去实现对程序中可能出现的异常进行集中处理。

　　与goto语句的作用类似，它能实现本地的跳转

　　这种情况容易理解，不过还是列举出一个示例程序吧！如下：

void main( void )
{
int jmpret;

jmpret = setjmp( mark );
if( jmpret == 0 )
{
// 其它代码的执行
// 判断程序远行中，是否出现错误，如果有错误，则跳转！
if(1) longjmp(mark, 1);

// 其它代码的执行
// 判断程序远行中，是否出现错误，如果有错误，则跳转！
if(2) longjmp(mark, 2);

// 其它代码的执行
// 判断程序远行中，是否出现错误，如果有错误，则跳转！
if(-1) longjmp(mark, -1);

// 其它代码的执行
}
else
{
// 错误处理模块
switch (jmpret)
{
case 1:
printf( "Error 1n");
break;
case 2:
printf( "Error 2n");
break;
case 3:
printf( "Error 3n");
break;
default :
printf( "Unknown Error");
break;
}
exit(0);
}

return;
}

　　上面的例程非常地简单，其中程序中使用到了异常处理的机制，这使得程序的代码非常紧凑、清晰，易于理解。在程序运行过程中，当异常情况出现后， 控制流是进行了一个本地跳转（进入到异常处理的代码模块，是在同一个函数的内部），这种情况其实也可以用goto语句来予以很好的实现，但是，显然 setjmp与longjmp的方式，更为严谨一些，也更为友善。程序的执行流如图17-1所示。

440){this.resized=true;this.style.width=440;}" style="cursor: pointer; width: 440px;" onclick="javascript:window.open(this.src);" src="http://bcbfans.shineblog.com/UploadFiles/2006-7/77830463.jpg" />

setjmp与longjmp相结合，实现程序的非本地的跳转

　　呵呵！这就 是goto语句所不能实现的。也正因为如此，所以才说在C语言中，setjmp与longjmp相结合的方式，它提供了真正意义上的异常处理机制。其实上 一篇文章中的那个例程，已经演示了longjmp函数的非本地跳转的场景。这里为了更清晰演示本地跳转与非本地跳转，这两者之间的区别，我们在上面刚才的 那个例程基础上，进行很小的一点改动，代码如下：

void Func1()
{
// 其它代码的执行
// 判断程序远行中，是否出现错误，如果有错误，则跳转！
if(1) longjmp(mark, 1);
}

void Func2()
{
// 其它代码的执行
// 判断程序远行中，是否出现错误，如果有错误，则跳转！
if(2) longjmp(mark, 2);
}

void Func3()
{
// 其它代码的执行
// 判断程序远行中，是否出现错误，如果有错误，则跳转！
if(-1) longjmp(mark, -1);
}

void main( void )
{
int jmpret;

jmpret = setjmp( mark );
if( jmpret == 0 )
{
// 其它代码的执行

// 下面的这些函数执行过程中，有可能出现异常
Func1();

Func2();

Func3();

// 其它代码的执行
}
else
{
// 错误处理模块
switch (jmpret)
{
case 1:
printf( "Error 1n");
break;
case 2:
printf( "Error 2n");
break;
case 3:
printf( "Error 3n");
break;
default :
printf( "Unknown Error");
break;
}
exit(0);
}

return;
}

　　回顾一下，这与C++中提供的异常处理模型是不是很相近。异常的传递是可以跨越一个或多个函数。这的确为C程序员提供了一种较完善的异常处理编程的机制或手段。

setjmp和longjmp使用时，需要特别注意的事情

　 　1、setjmp与longjmp结合使用时，它们必须有严格的先后执行顺序，也即先调用setjmp函数，之后再调用longjmp函数，以恢复到先 前被保存的“程序执行点”。否则，如果在setjmp调用之前，执行longjmp函数，将导致程序的执行流变的不可预测，很容易导致程序崩溃而退出。请 看示例程序，代码如下：

class Test
{
public:
Test() {printf("构造对象n");}
~Test() {printf("析构对象n");}
}obj;

//注意，上面声明了一个全局变量obj

void main( void )
{
int jmpret;

// 注意，这里将会导致程序崩溃，无条件退出
Func1();
while(1);

jmpret = setjmp( mark );
if( jmpret == 0 )
{
// 其它代码的执行

// 下面的这些函数执行过程中，有可能出现异常
Func1();

Func2();

Func3();

// 其它代码的执行
}
else
{
// 错误处理模块
switch (jmpret)
{
case 1:
printf( "Error 1n");
break;
case 2:
printf( "Error 2n");
break;
case 3:
printf( "Error 3n");
break;
default :
printf( "Unknown Error");
break;
}
exit(0);
}

return;
}

　　上面的程序运行结果，如下：
　　构造对象
　　Press any key to continue

　　的确，上面程序崩溃了，由于在Func1()函数内，调用了longjmp，但此时程序还没有调用setjmp来保存一个程序执行点。因此，程 序的执行流变的不可预测。这样导致的程序后果是非常严重的，例如说，上面的程序中，有一个对象被构造了，但程序崩溃退出时，它的析构函数并没有被系统来调 用，得以清除一些必要的资源。所以这样的程序是非常危险的。（另外请注意，上面的程序是一个C++程序，所以大家演示并测试这个例程时，把源文件的扩展名 改为xxx.cpp）。

　　2、除了要求先调用setjmp函数，之后再调用longjmp函数（也即longjmp必须有对应的setjmp函数）之外。另外，还有一个很重要的规则，那就是longjmp的调用是有一定域范围要求的。这未免太抽象了，还是先看一个示例，如下：

int Sub_Func()
{
int jmpret, be_modify;

be_modify = 0;

jmpret = setjmp( mark );
if( jmpret == 0 )
{
// 其它代码的执行
}
else
{
// 错误处理模块
switch (jmpret)
{
case 1:
printf( "Error 1n");
break;
case 2:
printf( "Error 2n");
break;
case 3:
printf( "Error 3n");
break;
default :
printf( "Unknown Error");
break;
}

//注意这一语句，程序有条件地退出
if (be_modify==0) exit(0);
}

return jmpret;
}

void main( void )
{
Sub_Func();

// 注意，虽然longjmp的调用是在setjmp之后，但是它超出了setjmp的作用范围。
longjmp(mark, 1);
}

　　如果你运行或调试（单步跟踪）一下上面程序，发现它真是挺神奇的，居然longjmp执行时，程序还能够返回到setjmp的执行点，程序正常退出。但是这就说明了上面的这个例程的没有问题吗？我们对这个程序小改一下，如下：

int Sub_Func()
{
// 注意，这里改动了一点
int be_modify, jmpret;

be_modify = 0;

jmpret = setjmp( mark );
if( jmpret == 0 )
{
// 其它代码的执行
}
else
{
// 错误处理模块
switch (jmpret)
{
case 1:
printf( "Error 1n");
break;
case 2:
printf( "Error 2n");
break;
case 3:
printf( "Error 3n");
break;
default :
printf( "Unknown Error");
break;
}

//注意这一语句，程序有条件地退出
if (be_modify==0) exit(0);
}

return jmpret;
}

void main( void )
{
Sub_Func();

// 注意，虽然longjmp的调用是在setjmp之后，但是它超出了setjmp的作用范围。
longjmp(mark, 1);
}

　　运行或调试（单步跟踪）上面的程序，发现它崩溃了，为什么？这就是因为，“在调用setjmp的函数返回之前，调用longjmp，否则结果不 可预料”（这在上一篇文章中已经提到过，MSDN中做了特别的说明）。为什么这样做会导致不可预料？其实仔细想想，原因也很简单，那就是因为，当 setjmp函数调用时，它保存的程序执行点环境，只应该在当前的函数作用域以内（或以后）才会有效。如果函数返回到了上层（或更上层）的函数环境中，那 么setjmp保存的程序的环境也将会无效，因为堆栈中的数据此时将可能发生覆盖，所以当然会导致不可预料的执行后果。

　　3、不要假象寄存器类型的变量将总会保持不变。在调用longjmp之后，通过setjmp所返回的控制流中，例程中寄存器类型的变量将不会被 恢复。（MSDN中做了特别的说明，上一篇文章中，这也已经提到过）。寄存器类型的变量，是指为了提高程序的运行效率，变量不被保存在内存中，而是直接被 保存在寄存器中。寄存器类型的变量一般都是临时变量，在C语言中，通过register定义，或直接嵌入汇编代码的程序。这种类型的变量一般很少采用，所 以在使用setjmp和longjmp时，基本上不用考虑到这一点。

　　4、MSDN中还做了特别的说明，“在C++程序中，小心对setjmp和longjmp的使用，因为setjmp和longjmp并不能很好 地支持C++中面向对象的语义。因此在C++程序中，使用C++提供的异常处理机制将会更加安全。”虽然说C++能非常好的兼容C，但是这并非是100% 的完全兼容。例如，这里就是一个很好的例子，在C++程序中，它不能很好地与setjmp和longjmp和平共处。在后面的一些文章中，有关专门讨论C ++如何兼容支持C语言中的异常处理机制时，会做详细深入的研究，这里暂且跳过。

总结

　 　主人公阿愚现在对setjmp与longjmp已经是非常钦佩了，虽然它没有C++中提供的异常处理模型那么好用，但是毕竟在C语言中，有这么好用的东 东，已经是非常不错了。为了更上一层楼，使setjmp与longjmp更接近C++中提供的异常处理模型（也即try()catch()语法）。阿愚找 到了不少非常有价值的资料。不要错过，继续到下一篇文章中去吧！让程序员朋友们“玩转setjmp与longjmp”，Let’s go！

不要忘记，前面我们得出过结论，C语言中提供的这种异常处理机制，与C++中的异常处理模型很相似。例如，可以定义出类似的try block（受到监控的代码）；catch block（异常错误的处理模块）；以及可以随时抛出的异常（throw语句）。所以说，我们可以通过一种非常有技巧的封装，来达到对setjmp和longjmp的使用方法（或者说语法规则），基本与C++中的语法一致。很有诱惑吧！

首先展示阿愚封装的在C语言环境中异常处理框架

　　1、首先是接口的头文件，主要采用“宏”技术！代码如下：

/*************************************************
* author: 王胜祥 *
* email: <mantx@21cn.com> *
* date: 2005-03-07 *
* version: *
* filename: ceh.h *
*************************************************/

/********************************************************************

This file is part of CEH(Exception Handling in C Language).

CEH is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

CEH is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

　　注意：这个异常处理框架不支持线程安全，不能在多线程的程序环境下使用。
如果您想在多线程的程序中使用它，您可以自己试着来继续完善这个
框架模型。
*********************************************************************/

#include <stdio.h>
#include <signal.h>
#include <setjmp.h>
#include <stdlib.h>
#include <float.h>
#include <math.h>
#include <string.h>

////////////////////////////////////////////////////
/* 与异常有关的结构体定义 */
typedef struct _CEH_EXCEPTION {
int err_type; /* 异常类型 */
int err_code; /* 错误代码 */
char err_msg[80]; /* 错误信息 */
}CEH_EXCEPTION; /* 异常对象 */

typedef struct _CEH_ELEMENT {
jmp_buf exec_status;
CEH_EXCEPTION ex_info;

struct _CEH_ELEMENT* next;
} CEH_ELEMENT; /* 存储异常对象的链表元素 */
////////////////////////////////////////////////////

////////////////////////////////////////////////////
/* 内部接口定义，操纵维护链表数据结构 */
extern void CEH_push(CEH_ELEMENT* ceh_element);
extern CEH_ELEMENT* CEH_pop();
extern CEH_ELEMENT* CEH_top();
extern int CEH_isEmpty();
////////////////////////////////////////////////////

/* 以下是外部接口的定义 */
////////////////////////////////////////////////////
/* 抛出异常 */
extern void thrower(CEH_EXCEPTION* e);

/* 抛出异常 (throw)
a表示err_type
b表示err_code
c表示err_msg
*/
#define throw(a, b, c)
{
CEH_EXCEPTION ex;
memset(&ex, 0, sizeof(ex));
ex.err_type = a;
ex.err_code = b;
strncpy(ex.err_msg, c, sizeof(c));
thrower(&ex);
}

/* 重新抛出原来的异常 (rethrow)*/
#define rethrow thrower(ceh_ex_info)
////////////////////////////////////////////////////

////////////////////////////////////////////////////
/* 定义try block（受到监控的代码）*/
#define try
{
int ___ceh_b_catch_found, ___ceh_b_occur_exception;
CEH_ELEMENT ___ceh_element;
CEH_EXCEPTION* ceh_ex_info;
memset(&___ceh_element, 0, sizeof(___ceh_element));
CEH_push(&___ceh_element);
ceh_ex_info = &___ceh_element.ex_info;
___ceh_b_catch_found = 0;
if (!(___ceh_b_occur_exception=setjmp(___ceh_element.exec_status)))
{

/* 定义catch block（异常错误的处理模块）
catch表示捕获所有类型的异常
*/
#define catch
}
else
{
CEH_pop();
___ceh_b_catch_found = 1;

/* end_try表示前面定义的try block和catch block结束 */
#define end_try
}
{
/* 没有执行到任何的catch块中 */
if(!___ceh_b_catch_found)
{
CEH_pop();
/* 出现了异常，但没有捕获到任何异常 */
if(___ceh_b_occur_exception) thrower(ceh_ex_info);
}
}
}

/* 定义catch block（异常错误的处理模块）
catch_part表示捕获一定范围内的异常
*/
#define catch_part(i, j)
}
else if(ceh_ex_info->err_type>=i && ceh_ex_info->err_type<=j)
{
CEH_pop();
___ceh_b_catch_found = 1;

/* 定义catch block（异常错误的处理模块）
catch_one表示只捕获一种类型的异常
*/
#define catch_one(i)
}
else if(ceh_ex_info->err_type==i)
{
CEH_pop();
___ceh_b_catch_found = 1;
////////////////////////////////////////////////////

////////////////////////////////////////////////////
/* 其它可选的接口定义 */
extern void CEH_init();
////////////////////////////////////////////////////

2、另外还有一个简单的实现文件，主要实现功能封装。代码如下：

/*************************************************
* author: 王胜祥 *
* email: <mantx@21cn.com> *
* date: 2005-03-07 *
* version: *
* filename: ceh.c *
*************************************************/

/********************************************************************

This file is part of CEH(Exception Handling in C Language).

CEH is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

CEH is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

注意：这个异常处理框架不支持线程安全，不能在多线程的程序环境下使用。
如果您想在多线程的程序中使用它，您可以自己试着来继续完善这个
框架模型。
*********************************************************************/

#include "ceh.h"

////////////////////////////////////////////////////
static CEH_ELEMENT* head = 0;

/* 把一个异常插入到链表头中 */
void CEH_push(CEH_ELEMENT* ceh_element)
{
if(head) ceh_element->next = head;
head = ceh_element;
}

/* 从链表头中，删除并返回一个异常 */
CEH_ELEMENT* CEH_pop()
{
CEH_ELEMENT* ret = 0;

ret = head;
head = head->next;

return ret;
}

/* 从链表头中，返回一个异常 */
CEH_ELEMENT* CEH_top()
{
return head;
}

/* 链表中是否有任何异常 */
int CEH_isEmpty()
{
return head==0;
}
////////////////////////////////////////////////////

////////////////////////////////////////////////////
/* 缺省的异常处理模块 */
static void CEH_uncaught_exception_handler(CEH_EXCEPTION *ceh_ex_info)
{
printf("捕获到一个未处理的异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
fprintf(stderr, "程序终止!n");
fflush(stderr);
exit(EXIT_FAILURE);
}
////////////////////////////////////////////////////

////////////////////////////////////////////////////
/* 抛出异常 */
void thrower(CEH_EXCEPTION* e)
{
CEH_ELEMENT *se;

if (CEH_isEmpty()) CEH_uncaught_exception_handler(e);

se = CEH_top();
se->ex_info.err_type = e->err_type;
se->ex_info.err_code = e->err_code;
strncpy(se->ex_info.err_msg, e->err_msg, sizeof(se->ex_info.err_msg));

longjmp(se->exec_status, 1);
}
////////////////////////////////////////////////////

////////////////////////////////////////////////////
static void fphandler( int sig, int num )
{
_fpreset();

switch( num )
{
case _FPE_INVALID:
throw(-1, num, "Invalid number" );
case _FPE_OVERFLOW:
throw(-1, num, "Overflow" );
case _FPE_UNDERFLOW:
throw(-1, num, "Underflow" );
case _FPE_ZERODIVIDE:
throw(-1, num, "Divide by zero" );
default:
throw(-1, num, "Other floating point error" );
}
}

void CEH_init()
{
_control87( 0, _MCW_EM );

if( signal( SIGFPE, fphandler ) == SIG_ERR )
{
fprintf( stderr, "Couldn't set SIGFPEn" );
abort();
}
}
////////////////////////////////////////////////////
　　体验上面设计出的异常处理框架
请花点时间仔细揣摩一下上面设计出的异常处理框架。呵呵！程序员朋友们，大家是不是发现它与C++提供的异常处理模型非常相似。例如，它提供的基本接口有 try、catch、以及throw等三条语句。还是先看个具体例子吧！以便验证一下这个C语言环境中异常处理框架是否真的比较好用。代码如下：

#include "ceh.h"

int main(void)
{
//定义try block块
try
{
int i,j;
printf("异常出现前nn");

// 抛出一个异常
// 其中第一个参数，表示异常类型；第二个参数表示错误代码
// 第三个参数表示错误信息
throw(9, 15, "出现某某异常");

printf("异常出现后nn");
}
//定义catch block块
catch
{
printf("catch块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
// 这里稍有不同，需要定义一个表示当前的try block结束语句
// 它主要是清除相应的资源
end_try
}

　　注意，上面的测试程序可是C语言环境下的程序（文件的扩展名请使用.c结尾），虽然它看上去很像C++程序。请编译运行一下，发现它是不是运行结果如下：
异常出现前

catch块，被执行到

　　捕获到一个异常，错误原因是：出现某某异常! err_type:9 err_code:15

　　呵呵！程序的确是在按照我们预想的流程在执行。再次提醒，这可是C程序，但是它的异常处理却非常类似于C++中的风格，要知道，做到这一点其实非常地 不容易。当然，上面异常对象的传递只是在一个函数的内部，同样，它也适用于多个嵌套函数间的异常传递，还是用代码验证一下吧！在上面的代码基础下，小小修 改一点，代码如下：

#include "ceh.h"

void test1()
{
throw(0, 20, "hahaha");
}

void test()
{
test1();
}

int main(void)
{
try
{
int i,j;
printf("异常出现前nn");

// 注意，这个函数的内部会抛出一个异常。
test();

throw(9, 15, "出现某某异常");

printf("异常出现后nn");
}
catch
{
printf("catch块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
end_try
}

　　同样，在上面程序中，test1()函数内抛出的异常，可以被上层main()函数中的catch block中捕获到。运行结果就不再给出了，大家可以自己编译运行一把，看看运行结果。
另外这个异常处理框架，与C++中的异常处理模型类似，它也支持try catch块的多层嵌套。很厉害吧！还是看演示代码吧！，如下：

#include "ceh.h"

int main(void)
{
// 外层的try catch块
try
{
// 内层的try catch块
try
{
throw(1, 15, "嵌套在try块中");
}
catch
{
printf("内层的catch块被执行n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);

printf("外层的catch块被执行n");
}
end_try

throw(2, 30, "再抛一个异常");
}
catch
{
printf("外层的catch块被执行n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
end_try
}

　　请编译运行一下，程序的运行结果如下：
　　内层的catch块被执行
　　捕获到一个异常，错误原因是：嵌套在try块中! err_type:1 err_code:15
　　外层的catch块被执行
　　捕获到一个异常，错误原因是：再抛一个异常! err_type:2 err_code:30

　　还有，这个异常处理框架也支持对异常的分类处理。这一点，也完全是模仿C++中的异常处理模型。不过，由于C语言中，不支持函数名重载，所以语法上略有不同，还是看演示代码吧！，如下：

#include "ceh.h"

int main(void)
{
try
{
int i,j;
printf("异常出现前nn");

throw(9, 15, "出现某某异常");

printf("异常出现后nn");
}
// 这里表示捕获异常类型从4到6的异常
catch_part(4, 6)
{
printf("catch_part(4, 6)块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
// 这里表示捕获异常类型从9到10的异常
catch_part(9, 10)
{
printf("catch_part(9, 10)块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
// 这里表示只捕获异常类型为1的异常
catch_one(1)
{
printf("catch_one(1)块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
// 这里表示捕获所有类型的异常
catch
{
printf("catch块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
end_try
}

　　请编译运行一下，程序的运行结果如下：
　　异常出现前

catch_part(9, 10)块，被执行到
　　捕获到一个异常，错误原因是：出现某某异常! err_type:9 err_code:15

　　与C++中的异常处理模型相似，它这里的对异常的分类处理不仅支持一维线性的；同样，它也支持分层的，也即在当前的try catch块中找不到相应的catch block，那么它将会到上一层的try catch块中继续寻找。演示代码如下：

#include "ceh.h"

int main(void)
{
try
{
try
{
throw(1, 15, "嵌套在try块中");
}
catch_part(4, 6)
{
printf("catch_part(4, 6)块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
end_try

printf("这里将不会被执行到n");
}
catch_part(2, 3)
{
printf("catch_part(2, 3)块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
// 找到了对应的catch block
catch_one(1)
{
printf("catch_one(1)块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
catch
{
printf("catch块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
end_try

}

　　到目前为止，大家是不是已经觉得，这个主人公阿愚封装的在C语言环境中异常处理框架，已经与C++中的异常处理模型95%相似。无论是它的语法结构；还是所完成的功能；以及它使用上的灵活性等。下面我们来看一个各种情况综合的例子吧！代码如下：

#include "ceh.h"

void test1()
{
throw(0, 20, "hahaha");
}

void test()
{
test1();
}

int main(void)
{
try
{
test();
}
catch
{
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
end_try

try
{
try
{
throw(1, 15, "嵌套在try块中");
}
catch
{
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
end_try

throw(2, 30, "再抛一个异常");
}
catch
{
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);

try
{
throw(0, 20, "嵌套在catch块中");
}
catch
{
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
end_try
}
end_try
}

　　请编译运行一下，程序的运行结果如下：
　　捕获到一个异常，错误原因是：hahaha! err_type:0 err_code:20
　　捕获到一个异常，错误原因是：嵌套在try块中! err_type:1 err_code:15
　　捕获到一个异常，错误原因是：再抛一个异常! err_type:2 err_code:30
　　捕获到一个异常，错误原因是：嵌套在catch块中! err_type:0 err_code:20

　　最后，为了体会到这个异常处理框架，更进一步与C++中的异常处理模型相似。那就是它还支持异常的重新抛出，以及系统中能捕获并处理程序中没有catch到的异常。看代码吧！如下：

#include "ceh.h"

void test1()
{
throw(0, 20, "hahaha");
}

void test()
{
test1();
}

int main(void)
{
// 这里表示程序中将捕获浮点数计算异常
CEH_init();

try
{
try
{
try
{
double i,j;
j = 0;
// 这里出现浮点数计算异常
i = 1/j ;

test();

throw(9, 15, "出现某某异常");
}
end_try
}
catch_part(4, 6)
{
printf("catch_part(4, 6)块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
catch_part(2, 3)
{
printf("catch_part(2, 3)块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);
}
// 捕获到上面的异常
catch
{
printf("内层的catch块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);

// 这里再次把上面的异常重新抛出
rethrow;

printf("这里将不会被执行到n");
}
end_try
}
catch_part(7, 9)
{
printf("catch_part(7, 9)块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);

throw(2, 15, "出现某某异常");
}
// 再次捕获到上面的异常
catch
{
printf("外层的catch块，被执行到n");
printf("捕获到一个异常，错误原因是：%s! err_type:%d err_code:%dn",
ceh_ex_info->err_msg, ceh_ex_info->err_type, ceh_ex_info->err_code);

// 最后又抛出了一个异常，
// 但是这个异常没有对应的catch block处理，所以系统中处理了
throw(2, 15, "出现某某异常");
}
end_try
}

#else
//
// For retail builds, use forced messages based on the zones turned on below.
//
#define ZONE_TEST 0
#define ZONE_PARAMS 0
#define ZONE_VERBOSE 0
……
#define ZONE_WARN 0
#define ZONE_ERROR 0

作者：宋宝华 出处：天极网

引言

　　C/C++语言有一个不同于其它语言的特性，即其支持可变参数，典型的函数如printf、scanf等可以接受数量不定的参数。如：

　　函数max中首先定义了可变参数表指针ap，而后通过va_start ( ap, num )取得了参数表首地址（赋给了ap），其后的for循环则用来遍历可变参数表。这种遍历方式与我们在数据结构教材中经常看到的遍历方式是类似的。

函数max看起来简洁明了，但是实际上printf的实现却远比这复杂。max函数之所以看起来简单，是因为：

　　(1) max函数可变参数表的长度是已知的，通过num参数传入；

　　(2) max函数可变参数表中参数的类型是已知的，都为int型。

　　而printf函数则没有这么幸运。首先，printf函数可变参数的个数不能轻易的得到，而可变参数的类型也不是固定的，需由格式字符串进行识别（由%f、%d、%s等确定），因此则涉及到可变参数表的更复杂应用。

　　下面我们以实例来分析可变参数表的高级应用。

高级应用

　　下面这个程序是我们为某嵌入式系统（该系统中CPU的字长为16位）编写的在屏幕上显示格式字符串的函数 DrawText，它的用法类似于int printf ( const char *format, ... )函数，但其输出的目标为嵌入式系统的液晶显示屏幕（LED）。

　　最终，我们用DrawText ( BYTE xPos, BYTE yPos, LPBYTE lpStr, ... )函数代替了原先所有的输出函数，程序得到了简化。就这样，兄弟们用得爽翻了。

运行机制探索

　　通过第2节我们学会了可变参数表的使用方法，相信喜欢抛根问底的读者还不甘心，必然想知道如下问题：

　　（1）为什么按照第2节的做法就可以获得可变参数并对其进行操作？

　　（2）C/C++在底层究竟是依靠什么来对这一语法进行支持的，为什么其它语言就不能提供可变参数表呢？

　　我们带着这些疑问来一步步进行摸索。

　　3.1 调用机制反汇编

　　反汇编是研究语法深层特性的终极良策，先来看看2.2节例子中主函数进行max ( 5, 5, 6 ,3 ,8 ,5)调用时的反汇编：