今天是冬至，也是入冬以来感觉最冷的一天，毫不夸张的说：你一张嘴，牙就冻上了。上午LP在家收拾卫生，我继续用Scons改造现有的项目。下午出去理发，头发长长了后，似乎会造成思维迟钝^_^。

试验性的用Scons改造现有的project，过程中对Scons了解又多了一些。上篇文章对Scons的性能没有给出定论，经过对Scons的深入后，发现Scons在执行初始时的性能的确不够快，这是因为Scons启动后，会对全部SConstruct以及下面子目录中的SConscript进行分析，子目录越多Sconscript文件个数越多，性能也就越差。但是这种分析也有一个优点，就是能帮你提前发现你SConscript中的一些“语义”错误，比如如果你在编译两个基础库，一个叫add，一个叫sub，这个基础库源码分别分布在两个目录add和sub中，编译后将分别生成libadd.a和libsub.a的库文件，但是如果你马虎了，在编写SConscript时将target都写成了'add'或都写成了'sub'，则Scons会在执行gcc之前就帮你找出这个"语义"错误，提示如下：
/export/home1/tony_bai/xxlib>scons -f SC*t
scons: Reading SConscript files …
scons: *** Multiple ways to build the same target were specified for: /export/home1/tony_bai/xxlib/lib/libsub.a  (from ['/export/home1/tony_bai/xxlib/add/libsub.a'] and from ['libsub.a'])
File "/export/home1/tony_bai/xxlib/sub/SConscript", line 3, in

Scons脚本基本写的差不多了，编译也ok了，但是编译出来的可执行程序在执行时却出现了问题：提示找不到某.so文件。而用项目"原配"的Makefile编译出来的可执行程序却执行的很好，没有类似问题，百思不得其解。将.so文件所在目录放到"LD_LIBRARY_PATH"中，问题得以解决，但这更加深了对这一现象的质疑。起初我一直以为是Scons在编译选项上不规范造成的，而Scons使用gcc -G -o xx.so xx.o来编译也的确有值得的怀疑点，-G选项是我从未见过的gcc编译选项，查了半天手册也没有对该参数的说明，遂放弃。上工具吧！先用ldd对编译出来的可执行文件进行分析，我们先来假设用Scons编译出来的可执行程序名字为Bin-scons，用"原配"Make编译出来的可执行程序名字为Bin-make。ldd将列出可执行文件中动态依赖的库的名字，并在本机定位出各个动态库的位置。对Bin-scons和Bin-make分别ldd的结果却让我大吃一惊，Bin-scons的ldd结果很正常，xx.so出现在list中，并且其位置为我刚刚加入到LD_LIBRARY_PATH中的那个目录；但是Bin-make的ldd结果中却不见了xx.so的踪影，这是怎么回事呢？回头翻看Makefile，并且又执行了多遍Make，项目的Makefile明明是构造了xx.so，在生成Bin-make时链接了xx.so，并且Bin-make中使用了xx.so中提供的接口。再次仔细对比Make和Scons编译.so时的差别，这回发现了些许不同的地方，"原配"的make在编译.so时，除了用了-shared -fPIC之外，还用了"-c"选项，而从Scons日志中只能看到gcc -G -o libxx.so xx.pic.o，显然Scons先控制gcc将xx.c编译为xx.pic.o，再由xx.pic.o构成libxx.so，而且我发现用Scons和Make编译出的.so文件大小居然不同。显然"-c"对两个编译过程带来了影响。一般来说，我们在编译一个动态库时是不会使用"-c"的，这里先不论项目Makefile写的是否ok，单说"-c"会给编译过程带来什么吧。打开gcc的"–verbose"开关，我们来试试使用和不使用"-c"gcc都做了些什么。还是以add.c为例，将add.c编译为libadd.so。

gcc -o libadd.so -shared -fPIC -c add.c –verbose
执行结果：
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: ../configure –with-as=/usr/ccs/bin/as –with-ld=/usr/ccs/bin/ld –disable-nls
Thread model: posix
gcc version 3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc add.c -quiet -dumpbase add.c -version -fPIC -o /var/tmp//cca0mHxn.s
GNU CPP version 3.2 (cpplib) (sparc ELF)
GNU C version 3.2 (sparc-sun-solaris2.9)
        compiled by GNU C version 3.2.
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
#include "…" search starts here:
#include search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/include
End of search list.
 /usr/ccs/bin/as -V -Qy -s -K PIC -o libadd.so /var/tmp//cca0mHxn.s
/usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 Solaris_9_CBE 2001/04/02

gcc -o libadd.so -shared -fPIC add.c –verbose
执行结果：
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: ../configure –with-as=/usr/ccs/bin/as –with-ld=/usr/ccs/bin/ld –disable-nls
Thread model: posix
gcc version 3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc add.c -quiet -dumpbase add.c -version -fPIC -o /var/tmp//ccz128Nl.s
GNU CPP version 3.2 (cpplib) (sparc ELF)
GNU C version 3.2 (sparc-sun-solaris2.9)
        compiled by GNU C version 3.2.
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
#include "…" search starts here:
#include search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/include
End of search list.

 /usr/ccs/bin/as -V -Qy -s -K PIC -o /var/tmp//ccoU5RTD.o /var/tmp//ccz128Nl.s
/usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 Solaris_9_CBE 2001/04/02
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy -o libadd.so /usr/local/lib/gcc-lib/sparc-sun-
solaris2.9/3.2/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtbegin.o -L/usr/local/lib/gcc-lib/sparc-sun-
solaris2.9/3.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/../../.. /var/tmp//ccoU5RTD.o -lgcc_s -lgcc_s
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtend.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtn.o
ld: Software Generation Utilities – Solaris Link Editors: 5.9-1.276

对比这两次的执行结果，我们可以发现，使用了-c的编译过程实际上不是一个完整的共享库(动态库.so)的构建过程，而只是一个带有"-shared, -fPIC"的目标文件(.o)的编译过程，缺少gcc crt目标文件的链接过程，只是目标文件被命名为libadd.so了。这恰恰能解释我们前面提到了两点疑问了。为什么ldd Bin-make时没有发现其依赖xx.so以及Bin-make执行时一切ok，没有报“找不到xx.so”，这一切都是因为xx.so实际上是以.o形式存在的一个文件，在构建Bin-make链接xx.so时，实际上做到是静态链接而不是动态链接，xx.so中的接口代码都已经存在于Bin-make中了，所以ldd无法找到对xx.so的依赖，Bin-make执行时也无需找到xx.so了。看来这是项目Makefile中的一个问题了，只是这个"问题"隐藏太久而未能被发现罢了。

从收音机中得知"冬至"这天应该吃饺子，晚上和LP煮了两包水饺，热腾腾的，吃得直打饱嗝^_^。

部门的一套基础库刚刚移植到Linux上，为了测试该库，我将工作环境切换到了Ubuntu Linux下面。切换后居然发现Ubuntu下的Firefox访问网页巨慢无比，Firefox显示时明时暗，总是被挂起。同样的公司网络环境在Windows下使用Firefox访问互联网很顺畅，没有卡的现象。看来是时候给Ubuntu下的firefox提提速了。

Google了一下才发现反映类似现象的人为数不少啊，在Ubuntu中文论坛中得到了一些答案。有人建议关闭ipv6；还有人则建议install dnsmasq。不是很明白其中的理由，照做就是了。

首先关闭IPv6。打开一个终端，在终端下输入："gksudo gedit /etc/modprobe.d/aliases"；在文件中搜索到"alias net-pf-10 ipv6"，注释掉其所在行，保存退出。再在终端下输入："gksudo gedit /etc/modprobe.d/blacklist"，在其中加上一行"blacklist ipv6 "，保存退出。最后重启系统使之生效。验证IPv6是否被关闭的方法：打开一个终端输入："ip a | grep inet6"，如果没有任何输出就说明 IPv6确实被关闭了。

其次，安装dnsmasq。在终端命令行下执行“sudo apt-get install dnsmasq”，安装完毕后，执行sudo gedit /etc/dnsmasq.conf，将“#resolv-file=”一行替换为"resolv-file=/etc/resolv.dnsmasq.conf"。然后执行“sudo cp /etc/resolv.conf /etc/resolv.dnsmasq.conf”，再编辑/etc/resolv.conf文件，保证在该文件中只保留"nameserver 127.0.0.1"一行即可，然后重启系统使dnsmasq生效。

果不其然，重启后的firefox恢复了和在Windows上一样的迅捷，不过遗憾的是由于修改了两处，不知道到底是上面哪种方法真正有效果的^_^。BTW，我的Ubuntu是7.10的，其自带的Firefox还是2.0.0.6版的，目前Firefox for Linux最新版已经是3.0.4了，这次顺便将firefox升级。使用apt-get居然没有3.0.4版的源，无法在线安装。更新源挺耗时的，还是直接到mozilla网站上下载吧。下载后的firefox是一个tar.bz2的包，这个如何安装呢？以前都是apt-get install的，还没有这么安装过，还好有Google。Ubuntu默认的firefox-2.0版安装在/usr/lib/firefox下，在/usr/bin下有firefox的一个符号链接。你通过命令行执行firefox或者点击桌面firefox图标启动firefox时实际上执行的都是/usr/lib/firefox/下的可执行文件，这样我就将下载的3.0.4的安装包通过tar -jxvf解压到本地目录，将/usr/lib/firefox备份，将解压后的3.0.4版本目录移到/usr/lib下，目录名仍然称作firefox，这样就可以顺滑过渡到3.0版了。现在你再启动firefox，查看“About”，就会看到版本已经升级到3.0.4了^_^。

上午发现同事的办公桌上摆着一款明晃晃的iPhone。这是我第一次如此近距离接触iPhone，第一印象就是"简洁"，机身正面只有一个圆按钮，其余都是屏幕，黑色的机身透露着高贵。拿起来，挺沉，后盖应该是金属的，做工很精致。按下圆按钮，屏幕亮起，很清晰。屏幕上显示的菜单看起来与普通诺基亚手机的菜单分布没有太大区别。想滑动窗口看看还有多少菜单项，居然找不到箭头，经iPhone主人提示：用手指轻轻在屏幕上一划，屏幕就滚动到下一屏，太帅了。同事说iPhone就是游戏机，里面的实况足球游戏很好玩，我也打开游戏尝试了一吧。游戏在iPhone的屏幕左下角模拟显示了一个十字方向键，在右下角则模拟有A, B键。刚开始玩时还不适应，因为始终感觉手指上没有反馈的感觉，毕竟手指直接接触平直的屏幕完成控制挺难的，控制好也许更难。游戏特别流畅，难怪Android平台的founder Andy Rubin说iPhone与5年前一台PC的配置不相上下。iPhone在bestbuy网站最低卖价199美刀。不过需要和AT&T签署协议，核算下来与在国内买一个水货的成本不相上下了。Android平台目前虽未成熟，但发展势头也很快，不久的将来Android和iPhone之间势必有一场激烈的竞争。