自从上次'编译Ethereal On Windows'之后，好久没有接触Ethereal了，前期策划的基于Ethereal开发的一个工具的任务就落到了这批来的一个新员工的头上了。第一阶段他在Windows上开发了一个基于Ethereal的插件用于分析CMPP协议之用；第二个阶段我们需要移植到Unix上，我们使用的是Solaris。

目标机器是一个x86的Solaris10的系统，首先是将Ethereal依赖的所有开源包都先装上。开源的唯一不好的一点就是互相依赖太多，像Ethereal这样规模的软件，依赖的包不下十几种。这里我们用的源码包是ethereal-0.99.0。按照常规编译软件包的方法：解包=>进入Ethereal目录=>执行./configure => make。

如果想一次make成功显然是不太可能的。

我的那个新同事第一次make得到如下结果：
libtool: link: only absolute run-paths are allowed，他查找了好久，终于"投降"了。由于是新同事对Unix上繁芜复杂的操作不了解也是情有可原的，亲自出马吧。

我对libtool同样是不熟悉，到网上找答案吧。网上关于这个错误的解释太少了。只能用"only absolute run-paths are allowed"在libtool这个脚本文件里搜索，果然找到了，有两个地方有这样的echo输出。大致检查了一下，基本定位问题所在：在libtool执行的语句中，有类似"-R../lib"这样的参数选项，显然这个"../lib"不是一个绝对路径，我们需要针对这个地方进行一下手工修改。

目标就是Makefile文件。打开Makefile搜寻"../lib"，一共有4处，分别在SNMP_LIBS、ethereal_LDADD、tethereal_LDADD和dftest_LDADD的定义中，在其中删除"-R../lib"或者为-R指定一个绝对路径即可。

问题解决，继续Make。还是没有过去，提示：在"/usr/sfw/lib/.libs下找不到libnetsnmp.so"，Makefile中明明配置的是/usr/sfw/lib，且该路径下存在libnetsnmp.so，为什么libtool非要到"/usr/sfw/lib/.libs"下找呢？libtool就是这样一个怪脾气，没办法，创建/usr/sfw/lib/.libs路径，并将libnetsnmp.so拷贝进去，在Make这块就过去了。

问题仍然层出不穷，程序在链接tethereal的时候，提示：ld: fatal: Symbol referencing errors. No output written to .libs/tethereal
Undefined                       first referenced
 symbol                             in file
gsm_a_pd_str                        tap-gsm_astat.o
RegistrationRejectReason_vals       tap-h225counter.o
register_all_protocol_handoffs      tethereal.o

继续在网上搜索，还好有类似的问题别人也遇到了，解决方法：将epan/dissectors/.libs/libdissectors.a加到Makefile中多个变量的定义中。下面是详细的修改：
(1)
tethereal_additional_libs = \
        wiretap/libwiretap.la           \
        epan/libethereal.la

=>

tethereal_additional_libs = \
        wiretap/libwiretap.la           \
        epan/libethereal.la \
        epan/dissectors/.libs/libdissectors.a \

(2)
dftest_additional_libs = \
        wiretap/libwiretap.la           \
        epan/libethereal.la \
=>
dftest_additional_libs = \
        wiretap/libwiretap.la           \
        epan/libethereal.la \
        epan/dissectors/.libs/libdissectors.a
(3)
dumpcap_LDADD = \
        $(dumpcap_additional_libs)      \
        -lgmodule-2.0 -lglib-2.0                        \
        -lpcap
=>
dumpcap_LDADD = \
        $(dumpcap_additional_libs)      \
        -lgmodule-2.0 -lglib-2.0                        \
        -lpcap -lsocket -lnsl
(4)
ethereal_additional_libs = \
        gtk/libui.a             \
        wiretap/libwiretap.la   \
        epan/libethereal.la \
=>
ethereal_additional_libs = \
        gtk/libui.a             \
        wiretap/libwiretap.la   \
        epan/libethereal.la \
        epan/dissectors/.libs/libdissectors.a \
这回你再make，哇，编译成功了。

然后敲入make install安装这个ethereal，在Windows上启动Xmanager(trial版)，连接到目标服务器，用root登录(如果没有root权限，是看不到网卡的，也就不能进行协议分析了)。进入/usr/local/bin，在这里我只发现了tethereal这个程序，执行起来也没有问题，但是那个图形界面的ethereal哪里去了。翻看install的日志，发现根本没有安装ethereal。怎么回事？

继续网上找答案，很快答案找到了：是否编译安装ethereal是configure决定的。在configure的执行日志我看到：
The Ethereal package has been configured with the following options.
                    Build ethereal : no
                   Build tethereal : yes
                    Build capinfos : yes
                     Build editcap : yes
                     Build dumpcap : yes
                    Build mergecap : yes
                   Build text2pcap : yes
                     Build idl2eth : yes
                     Build randpkt : yes
                      Build dftest : yes

显然Build ethereal : no。网上的理由是：GTK+版本安装不当。从configure日志看到：
checking for GTK+ – version >= 2.0.0… no
*** Could not run GTK+ test program, checking why…
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GTK+ is incorrectly installed.

这时只能重新检查GTK+，甚至是重新安装GTK+。

搞定这个后，再重新configure，注意别忘了备份上述对Makefile的修改，否则configure会覆盖你的成果。之后的工作这里就不说了。

毕业后就一直从事于服务器端程序的开发，主要客户是中国移动，大家知道移动的产品都是电信级的，稍出差错后果都是严重的，所以在我们平时的工作中除了研发之外，还有的就是对我们卖给移动的产品的维护性工作，而这种维护性工作要求就是要"迅速解决现场的问题"。这几个月维护工作占据了我很大一部分精力，说实话，有些烦了，但是从另外一个角度来看，也说明了我们的产品在维护性方面做的不够好，否则移动的工作人员或当地的技术支持人员通过手册或者查看系统日志的方式就可以解决问题的。这让我反思。

一般来说，我们的产品在交付时都是有详尽的用户手册的，现场人员可以根据维护手册来查找问题所在。另外维护工作也是分层次的，在运行我们产品的各省移动公司都有我们的当地技术支持人员，而移动自己的网管人员在多年的维护过程中也逐渐的积累了丰富的问题解决经验。一般问题发生后，移动的人员都会试着自己来尝试解决，当其无法解决时，会将问题告诉当地的技术支持人员，只有在技术支持人员也解决不了问题的时候，问题才会反馈给我们研发人员，而研发人员就成为了系统的最后一道保护伞了。移动人员的素质我们自然控制不了，我方技术人员我们会尽可能的通过培训和讲解的方式传授解决问题的办法，并通过他们自己在维护过程中积累经验，但是一旦问题提交给研发人员，我们就需要在远程以最快的时间将问题解决。

研发人员一般来说对业务熟悉，对功能是如何实现也有把握，但是一个系统往往是很庞大的，很可能是经过"几代人"前离后继"(前人离职了，后人来继承)完成的，所以到最后很可能整个产品组内没有一个人对整个系统的每个角落都了如指掌的，这时问题就出现了。

对于研发人员来说，他们最擅长的就是通过问题现象去到代码里分析，现场产品因为在运行，一般来说我们不可能去用调试工具直接调试现场运行的程序的。而问题的现象一般是通过系统日志体现出来的；也就是说在研发人员解决问题这层，系统的运行日志对解决问题起着至关重要的作用。这样一来系统日志设计的好坏直接会影响到你解决问题的效率和质量。

而通过日志定位问题所在的代码位置一般有如下几个现象：

[现象一]  当你用某一个错误日志去search in project的时候，居然发现：
if (condition1 | condition2 | condition3)
      你查询的日志输出;
输出该日志的条件是多个或的关系，而且每个condition也许是一个复杂的函数调用，这会大大延长你跟踪问题的时间；

解决方法：
a) 尽量减少condition1 | condition2 | condition3的使用；
b) 对于复杂和关键地方的处理，给出"点睛"的注释；

[现象二] 当你用某一个错误日志去search in project的时候，居然发现：
Project中存在不止一条这样的错误日志，其位置可能分布在Project的不同源文件中的不同位置。这同样会大大延长你跟踪问题的时间和难度。

解决方法：
我们套用"幸福的家庭往往是相同的,不幸的家庭各有各的不幸"来说明：成功的日志往往格式相同，失败的日志各有各的特征。如果每条错误日志的特点都不相同，那么当我们search的时候，就可以一次定位问题所在了。

[现象三] 当你用某一个错误日志去search in project的时候，居然发现：
该日志是在一个宏的定义中输出的，而该宏散布在Project的各个角落。

解决方法：
不要在宏(广泛使用的宏)中做任何日志输出。

当然上述的某些解决方法可能与代码的可读性或者精炼性有悖，这就要看你是如何抉择的了，根据具体情况三思而后行。

另外对于查找问题而言，关键而详尽的注释会给研发人员带来很大帮助，否则他就很可能陷入复杂的业务逻辑中，长时间不能自拔了。

以上一点私人见解，仅供参考。