九月二十六日记

　　今天把这个月的项目编码编译成程序，放到设备上跑，初步测试没有发现问题，无论是内存占用还是程序体积以及速度都比较符合我的要求，但是稳定性如何还>得进一步测试才能得知。
　　虽说只是生成程序这一步，却让我花了整整一个上午去处理。事情分一下发展阶段：
　　1、我面前有台PowerPC的设备，但是没有装编译环境，缺的工具也太多，于是就用头给的Buildroot来在我的i686下生成一个交叉编译环境。
　　2、郁闷的是由于路径或者别的原因，原本已经和Buildroot一起打包好编译环境的在我的机器下老提示找不到头文件，无奈只好自己重新下载一个纯净的版本来做，中间也稍微学到一些东西，起码下次再搭建别的架构的交叉编译环境也不会向今天这么没头绪。可能是机器CPU速度比较低的缘故，编译近3个小时才把powerpc-g++和我需要的一些库生成出来。
　　3、改makefile，编译，发现提示有未定义的符号，我明明把自己需要的链接库都放到上面的。但是改成静态编译就没有什么问题，可是原本50K的程序直接扩增到3500K，静态库太大，这个方法不够好。于是找到动态库，用objdump去看，发现没有段信息，我就奇怪了，为什么没有段信息呢，这样肯定链接不上呢。我就怀疑>我在配置Buildroot的时候选择的符号处理器，我所见识的无非就是strip，但是我按照头给的配置文件来用的是sstrip，多一个s会不会引发这样的问题呢。于是我问头，头儿说strip不会影响动态库的，我回答，但是我看原本配置的是sstrip，这个东西会不会呢？而且strip本身也有去掉段信息的选择项怎么会不影响呢。我决定>还是靠自己去实验。
　　4、在Buildroot目录下搜索我所需要的所有gmp相关的东西，找到另外一个路径下的gmp动态库，objdump一看是bigedin的而且有段和符号信息。于是把这个用strip处理下，发现符号信息没了，但是段信息还在。然后放到默认lib路径下再去make，这时候一切正常，毫无警告和错误提示。然后我又用sstrip去处理这个动态库，objdump下，段信息也消息，再去make，链接失败，看来果然是这个sstrip搞得鬼。不过我用刚才正常生成的程序和sstrip后的库放在一起，可以正常运行。看来缺失
的段信息会影响链接，但不影响运行，果然解决问题还要靠自己。
　　就在我中午忙着搭建环境的时候，同桌的同事对我说，他要走了。我放下手中的活，目送他离去，这一走，就不会回来，于是人，又少了一个。原本百多人的分公司到如今只剩下我们5个人的技术团队，江河日下。这大都是决策层犯的错误，却让下面的人去承担这些责任，不禁想起一句西方的谚语：老人们在后方搞政治，小伙子们在前线卖命。不想为别人卖命怎么办，那就努力成长到可以为自己卖命的水平。
　　
[dave@fedora davehome]$ make love
make: *** No rule to make target `love'.  Stop.