春节过后，项目一直比较忙，我的Ubuntu自从上周日安装到系统中后就一直没有怎么用过，好不容易盼到周末了，这回可有时间体验一下'热得烫手'的Ubuntu了。Dreamhead在评论中给我的建议是:坚持使用Ubuntu，你就会越用越熟练的。这同样也是我的想法，所以首要的任务就是先体验一下Ubuntu，看其是否能满足我工作和平时娱乐的需要。
 
Linux总是让新手'迷路',我所说的'迷路'是指在进入Linux后'不知所错'。下面就说说我在Ubuntu下的一步一步的体验经历。

刚刚装好Ubuntu，并成功登入桌面后，我还是蛮兴奋的，毕竟安装过程一番风顺，且Ubuntu自动找到了我的D-LINK无线路由器，经过简单设置就可以连上Internet了，有了网络就好像插上了翅膀，有什么问题也就不怕了。Ubuntu默认的Gnome桌面很是简洁，位于桌面上方的菜单栏中放置了所有有用的菜单项。Ubuntu内置了许多有用的开源应用，比如：Firefox、OpenOffice系列等，这些满足你的基本需求是没有问题的。但是一般使用Ubuntu的Fans是不满足于此的。我们要对Ubuntu进行充分的挖掘。

Ubuntu的默认字体说实话是很难看的，而且初始情况下是不支持中文输入法的。所以安装中文输入法和中文字体就成为了我的首要任务。如果说通过看资料就能熟练掌握Ubuntu是不行的，那么一点资料不看，自己捅咕也是万万不行的。

按照网上资料的做法，在命令行中敲入类似:sudo apt-get install in-switch scim scim-pinyin scim-tables-zhscim-bridge的命令，回车后，居然提示：找不到in-switch包，反复在root和应用用户下试了多次都提示找不到，郁闷中继续在网上搜索，直到发现ubuntu官方wiki中的一篇'快速设置指南'的文章，我这才'茅塞顿开'。原来Ubuntu在安装后的第一步就是所谓'更新源（即/etc/apt/sources.list）'。sources.list在初始情况下是不存在的，我们需要首先编辑/etc/apt/sources.list，在sources.list中添加若干个Ubuntu服务器的url地址，编辑保存后执行sudo apt-get update。每次人工更新sources.list后都要执行一遍update。更新后，我们就可以执行sudo apt-get install package-name来安装需要的软件包了。Ubuntu的软件多为网络安装，apt-get install会自动从服务器上下载包并安装。这里的sudo又是什么意思呢？按照'快速设置指南'中的说法: sudo就是以超级用户执行[Superuser Do]的意思，这时你只需要输入你的用户密码即可按照超级用户权限执行install任务了。

首先，我还是按照前面的命令来安装in-switch、scim和scim-pinyin。网络安装是把'双刃剑'，好处在于你不用像在Windows上寻找软件那样到各大下载网站去下载了，你只需要敲入一个命令，apt-get就会替你到源服务器上去找去下载。但是缺点也是明显的，特别是在大陆，网络环境不好，下载很慢，一个scim就让我等得不耐烦了。另外是否每次重装ubuntu都要重新下载一次呢？起码在Windows上我下载一次安装文件后，我可以放到移动硬盘上保存备用。听说小企鹅输入法安装文件较小，可以用来替代scim，那就用小企鹅输入法吧。按照如下命令执行：
sudo apt-get install im-switch fcitx
sudo im-switch -s fcitx -z default
大约3M左右的fcitx输入法在10分钟之内就安装结束了。安装后的fcitx的确与系统自带的scim有冲突，指南中已经给出解决方法了，照做就是了。具体如下：
sudo gedit /usr/lib/gtk-2.0/2.10.0/immodule-files.d/scim-gtk2-immodule.immodules

将内容改为如下：
# automatically generated by dh_gtkmodules, do not edit
“/usr/lib/gtk-2.0/2.10.0/immodules/im-scim.so”
“scim” “SCIM Input Method” “scim” “/usr/share/locale” “ja:ko”
这样修改以后，scim在中文环境下将不被启动，也就不会于fcitx冲突了。

下面开始安装中文包支持以及中文字体。选择System->系统管理->Language Support,在打开的对话框中的Supported Language中选择Chinese，默认语言也选择Chinese，确定后，系统会提示需要安装语言包，安装就是了。语言包挺多挺大下载也挺慢，耐心吧。

Ubuntu默认带了一种叫：文鼎PL上海宋的字体，毫无疑问不能满足我们的审美观，我们需要另外安装自己喜欢的字体。在Ubuntu中文论坛上很多认推荐安装的是一种叫：文泉驿的开源中文字体，我也试试。执行sudo apt-get install xfonts-wqy，安装后重启X-Windows。然后在'System'->首选项 ->外观中将你想设置为文泉驿的地方都选择上即可。网上还有很多漂亮的字体，我就姑且先用这个吧。

Linux经过多年发展，其娱乐性也有了长足的进步，除了内置十多款小游戏外，还内置了多款影音播放软件。我打开其中一款叫RthythmBox，选择了一首MP3试图打开收听，让我气愤的是居然提示我:找不到mp3的解码器。按照网上的指示：sudo apt-get install w32codecs。心想这回总该可以了吧。结果点击play，问题依旧。提示找不到mp3 decoder。无奈中采用了一招windows下的打开mp3的方法：双击那个mp3文件，居然弹出一个对话框告诉我，找不到mp3的decoder，并提示是否下载restricted packages，下载就是了。也许mp3格式文件涉及版权或者某些专利吧，以致ubuntu没有将其纳入解码支持。当杨坤演唱的颇为震撼的集结号主题曲'兄弟'响起时，ubuntu的影音功能这才算配置好。

作为C开发人员，怎能离开gcc呢。打开命令行，输入gcc -v，得到的信息：gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)，ubuntu果然内置了gcc，而且版本也基本上是最新的了。写一个小'hello ubuntu'程序试试吧。执行gcc -o helloubuntu helloubuntu.c后一个error呈现在我的眼前，居然提示：找不到stdio.h！难道ubuntu下没有安装C标准库的头文件和库文件，经检查的确没有安装。没办法还得借助网络，好心人给出方法：执行sudo apt-get instal build-essential。果不其然，在build-essential安装到系统中后，hello ubuntu也得以顺利编译和执行了。

平时一直使用的是vim，众所周知vim支持定制，我把我的.vimrc文件放到了HOME目录下，执行vim，出乎意料的是vim提示：E319: Sorry, the command is not available in this version: syntax on。我仔细看了一下vim是7.1.x版本的，怎能连syntax on这种配置语法都不支持呢？在网上搜索了很久，终于在一个台湾地区的网站得到了答案：ubuntu的vim还是一个tiny version，的确连syntax on都不支持。你需要执行sudo apt-get install vim来重新安装full vim版本才能支持这些个性化配置。

Linux毕竟不是以桌面系统起家的，试用了这么长时间感觉在Ubuntu上用光标总是不那么顺手，特别是用笔记本的Touchpad(触控板)控制光标总是会有失误，稍不注意，就导致页面上下左右乱动。无奈中尽量强迫自己多记忆些快捷键组合，试用键盘还是比较精确的，另外对于程序员而言多记住一些快捷键是大有裨益的，习惯后可以大大提高工作效率。

最后牢骚一句：X-Window桌面在频繁鼠标、键盘事件发生时反映很是不灵敏，在写Blog的时候，Gedit多次失去了反应，无奈只能关闭重启。另外本篇blog就是在ubuntu linux下使用gedit编辑的^_^。

清晨，部门新来的一位小兄弟打来求助电话，说是系统启动的时候出现类似："ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到"的错误。这个系统是05年开发的一个复用度很高的自研产品，后续项目只需在其基础上做少量二次开发工作即可满足新功能的要求。为了做到一定的通用性，我们使用了类似插件的框架，这样系统在启动的时候会根据配置加载一些'共享库'(.so文件)，而这个小同事反映的问题就出在这。

上面仅仅是一个引子，在写下本篇文章之前，这个问题已经被解决，我的那个小同事在连续奋战14个小时(从昨晚21:00到今天上午11:00)后，终于也可以安心踏上返回四川老家的火车了。事后，我深入的想了一下这个问题，觉得有必要说一下。

这里用一个简单的例子来重现一下这个问题吧。我们先来准备一个静态链接库(.a)和一个动态共享库(.so)，都比较简单，能反映出问题就行。

[静态库]
//teststatic.h
int static_add(int a, int b);

//teststatic.c
#include "teststatic.h"
int static_add(int a, int b) {
        return a+b;
}

编译静态库：
gcc -c teststatic.c
ar crv libteststatic.a teststatic.o

[动态共享库]
//testshared.h
int dynamic_add(int a, int b);

//testshared.c
#include "testshared.h"
#include "teststatic.h"
int dynamic_add(int a, int b) {
        return static_add(a, b);
}

编译共享库：
gcc testshared.c -fPIC -shared -o libtestshared.so

然后，我们再写一个测试桩程序，其主要功能就是：通过dlopen和dlsym在运行时动态加载libtestshared.so，然后得到符号dynamic_add的地址，完成计算功能。
#include
#include

typedef int (*PTR)(int, int);

int main() {
        void    *handle = NULL;
        char    *errinfo = NULL;
        PTR     ptr;
        int     rv;

        handle = dlopen("./libtestshared.so", RTLD_LAZY);
        if (handle == NULL) {
                errinfo = dlerror();
                printf("dlopen失败: %s\n", errinfo);
                return;
        }

        ptr = (PTR)dlsym(handle, "dynamic_add");
        if (ptr == NULL) {
                errinfo = dlerror();
                printf("dlsym失败: %s\n", errinfo);
                return;
        }

        rv = ptr(1,2);
        printf("rv = %d\n", rv);
}
编译：gcc -o testmain testmain.c -ldl -L./ -lteststatic
运行结果：ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到，被杀掉。

通过运行结果分析：程序在启动时，链接程序并没有找到符号:static_add，无从知道其指令代码，所以报错。这个例子反映的就是我那个小同事犯的'错误'– 程序在加载阶段链接器无法resolve共享库里调用的其他函数符号。那为什么找不到呢？我们还需简单回顾一下程序启动阶段的一些事情。

程序启动后，由加载器(即常说的loader)将之加载到内存中，过程很复杂和繁琐，我们就说程序中的符号是如何resolved的(我是从John R.Levine的"Linkers & Loaders"一书中学到的一些皮毛)。加载阶段，加载器(很多工作由链接器完成)先进行自身的初始化，之后它会根据程序文件的头(Headers)中的信息，查找程序所需要的共享库(静态库是在编译期间就已经链接到程序本身中了)的名字，对于每一个共享库的名字，它都会在搜索路径下搜索该共享库是否存在，如果存在，则处理该共享库文件，处理包括：分配text和data段空间并进行映射，其符号表将被merge到主符号表里；如果该共享库文件依然有依赖的其他共享库，且该依赖的共享库在之前并未被load，则将该依赖的共享库加入到待加载的库列表中。

有人要说，上面的testmain程序与这个加载过程不同啊，testmain是用dlopen和dlsym在运行时而不是加载时加载.so的，其实按照John R.Levine的说法: "The two routines dlopen & dlsym are actually simple wrappers that call back into the dynamic linker"，也就是说：使用dlopen和dlsym的组合时，完成的事情和加载阶段链接器完成的事情是一样的。

那我们来看，testmain编译的时候是不依赖任何显式(C运行时和unix系统库等隐式的除外)的共享库的，那么在加载libtestshare.so时，遇到static_add这个符号时，就不知所措了。这里又有人要问了：编译testmain的时候不是链接了libteststatic.a这个库了吗，这个库里不是有static_add的符号吗？你可以nm testmain > dump.log看一下，看看dump.log中是否有static_add这个符号。其实细想一下也会知道：testmain.c中根本没有使用static_add，编译器当然不会无端将static_add的放入testmain的可执行文件中了，否则在unix系统下的每个用户级程序的'体格'都会极其庞大。

上面说过，因为testmain.c中没有使用static_add，所以不能动态加载so时，不能resolve这个符号，如果testmain.c中使用了static_add，那么程序就没有问题了吧？没错！看下面：
#include "teststatic.h"
… …
int main() {
        void    *handle = NULL;
        char    *errinfo = NULL;
        PTR     ptr;
        int     rv;
    
    rv = static_add(5, 6);
    printf("rv = %d\n", rv);

        … …

        rv = ptr(1,2);
        printf("rv = %d\n", rv);
}
这样一来，static_add就会体现在testmain的符号表里，作为testmain的一部分了。当运行时加载.so后，遇到static_add这个符号时，链接器就有据可依了。

又会有人问：我们不能要求所有.so中出现的符号在主程序中都要有吧？对，这样要求显然是无理的，那么如何是好呢？我们只能在编译.so时将这些符号静态链入.so，比如：gcc testshared.c -fPIC -shared -o libtestshared.so -L./ -lteststatic

我们可以通过nm命令看到链入静态库前后的不同：

未链入静态库时nm *.so，符号static_add处于UNDEF状态
[67]    |         0|       0|NOTY |GLOB |0    |UNDEF  |static_add
链入静态库后，nm *.so的结果：
[68]    |      1412|      36|FUNC |GLOB |0    |10     |static_add
static_add的代码被copy一份放到了.so中。

这里关于dlopen函数的第二个参数mode再多写两句。上面的例子中，我们传入的参数是RTLD_LAZY，什么意思呢？RTLD_LAZY是说：.so中的符号只有在其第一次使用的时候，才会由链接器计算出其实际地址，否则在.so加载时是不计算其实际地址的。原因也很简单：一个.so文件中可能有成百上千的符号，我们的程序也许只用到其中的一两个，如果加载时所有符号都要将其实际地址映射好，显然会降低运行时动态加载的性能。还是以testmain.c为例，如果代码中去掉对ptr(1,2)的调用，那么执行testmain是不会出错的。

dlopen中还提供了些许选项，比如：RTLD_NOW，从字面含义也可以猜测出来，其含义与RTLD_LAZY正相反，即.so加载时，其内部所有符号都要计算出实际地址。还以testmain.c为例：
handle = dlopen("./libtestshared.so", RTLD_NOW);
这时即使去掉对ptr(1,2)的调用，执行时会提示：dlopen失败: ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到。

看来，共享库中的符号链接没有想象中的那么容易，使用的时候要'小心'。也许正是这些需要你投入和认真思考的问题才让使用C语言进行底层或系统开发更具魅力。