今天把这个月的项目编码编译成程序,放到设备上跑,初步测试没有发现问题,无论是内存占用还是程序体积以及速度都比较符合我的要求,但是稳定性如何还>得进一步测试才能得知。
虽说只是生成程序这一步,却让我花了整整一个上午去处理。事情分一下发展阶段:
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.
最后一段是亮点
[dave@fedora davehome]$ make love
[e01]其实我对金山的《病毒分析师》一职很感兴趣
回复 kshaoye:额,这个活可大可小.小的就像人工分词一样无聊,大的可以让你学到操作系统,编程,加密解密中最先进最精密的部分.
一切都是看自己的意志了.