shit!Vxworks!Shit!WorkBench!
2010-12-03 19:04 Jeff 阅读(1620) 评论(0) 编辑 收藏 举报
郁闷的一周,一周的郁闷!
Fuck the Vxworks! Fuck the WorkBench!
终于在注释掉报错的几行代码后,不管三七二十一,先编译通过了.但是走到这一步,弯路走了不少.
记录下来,以儆效尤!下周再解决这几个编译错误,抑或是不解决?
1. 安装workbench 3.2的时候没有使用同一目录下的licence,安装不成功.安装成功后,用开发组给的2个label竟然想编译!
2. 拿到了一个config spec!然后是按照Vxworks 6.5的方法在Vxworks6.8环境下编译,结果报错.于是删掉project文件,结果删除project文件的时候,选择了同时删除workspace下的文件(脑子进水了!),但是workspace下文件是在clearcase里的。于是在下次import project的时候,出现了project无法编译的现象,其实是check out的project文件被删除了。于是在clear case里只能看到这个被check out了,但是找不到这个文件!更搞笑的是,当天从同事那里得知信息,这个应该是clearcase的问题,找CM解决。
3. 周末加班,在热心同事的帮助下,才意识到是check out的文件被删除了(其实自己已经意识到了,奶奶的,这个现象和unix下clearcase的现象是一样的啊,cleartool ls 是看不到这个文件的)。回复的方法:先创建同名的文件,然后uncheckout,然后再checkout.
4. 紧接着遇到的问题是编译项目的时候,一会儿会报一个license 的fatal error.以及一个VSB project的警告.只好发了一封信给有经验的同事,回家.
5. 同事告知是license的错误,并且给了一个正确的license的路径,放在环境变量里,重启电脑这个问题搞定.
6. 在使用Vxworks6.5方法还是编译不过的情况下,决定先编译目前项目A的dependency项目B.项目B恶搞了好久,还是编不过.随后从同事出得知是config spec的问题,之前给的config spec不对!
7. 拿到新的config spec之后还是编译不过!从错误中,编译通过的同事告知编译项目A checkout的一个文件在编译项目B的时候不应该check out!这个编译项目B大概需要3-4个小时,于是决定默认项目B已经编译通过,毕竟要3-4小时啊。而且自己使用的config spec和同事使用的完全一样,他们已经编译通过了,无需再浪费时间。
8. 于是再次把项目A的config spec加入到项目B的config spec中去,还是无法编译通过!
9. 意识到.wpj文件需要从Vxworks6.5 migrate到Vxworks 6.8. 使用workbench的 CLI命令搞定. 生产的kernel configuration有问题,需要在workbench中纠正这一错误。
10. 编译还有问题,随后咨询有经验同事,告诉我link文件有问题!于是把link文件改成Vxworks6.8上的,从其他project拷贝过来即可.
11. 编译错误变成无法识别inline函数.新版本inline函数是从其他的目录移过来的.这个inline函数用的还是K&R风格,参数类型的声明是在函数名字下面的,括号外面.如果改成非inline,非K&R吧,项目C编译不过,否则项目A不过
12. 挣扎良久之后,决定这2个文件用以前版本的。则这个问题解决了.这是因为项目A这样不再包含inline函数的代码。
13. 随后的一个问题,还是觉得是inline的问题,Undefined symbol.4个Undefined symbol的问题. 把这4个问题注释掉以后.勉强能编译出.hex文件.
悲剧啊!开发的任务还没有开始!环境的问题还没有解决!这个编译的问题不知道是否是地雷!
1. 重来没有用C/C++做过项目
2. 压根一点儿都不熟悉workbench
3. 对整个系统不熟悉,不了解各个子系统各自功能
4. Vxworks知识一点都无
5. 对源代码一知半解!