测试CORBA_manok_新浪博客

     这两天做CORBA的兼容性测试,因为我们的CORBA主要在Linux下使用,所以测试在各种Linux下的兼容性,而Linux的版本不统一,使得Linux下发布程序具有很大的风险。这主要因为Linux的各种共享库不一致,每个版本的程序都存在着一个依赖集。被测试程序是采用C++编写的,其依赖集主要包括Gnome库的版本,还有就是ORBit的版本。本次测试的Linux版本主要有red hat enterprise 3和4,red hat 8.0()和9.0(),CentOS4.3,AS4 64位版本。
   我们的程序开发是在AS4(32位)平台下开发的,所以主要测试包括,在刚安装的AS4上怎么配置,程序能正确执行。经过测试,在AS4上只要安装上Gnome就可以了。在CentOS上可以直接运行,因为其所使用的glib和ORB的版本兼容AS4上的这些软件版本,因为高版本可以兼容低版本,所以该系统上的测试在虚拟机上安装后,就验证通过了。当然我们只是做了操作系统的兼容性,并不包括与操作系统中程序、防火墙、杀毒程序等的兼容。
   测试完AS4后,接着测试red hat AS3时,可没有那么简单了,所有依赖的库都不兼容,先后安装了GCC、glib、ORBbit才最后通过,整整花费了一天的时间,主要是中间走了弯路,本来希望把后面安装的库放在单独的路径下,也就是不安装在/usr/lib 下,而安装在/opt/gnome下,通过在profile中设置LD_LIBRARY_PATH变量中共享库的路径,后面又通过ld.so.conf文件中设置,通过运行ldconfig重新刷新环境变量的方法,都不行,关键是在编译ORBit2.0时,提示需要的是glib0.8.2库,而系统中安装的是glib0.8.0,使用./configure --prefix=/opt/gnome做配置和依赖性检查时,总是出现上面的错误,后来终于找到了问题,Linux进行编译检查时,首先是检查 /lib 和/usr/lib这两个路径,然后再读取配置文件中的路径,如果前面找到了需要的库的路径,则不再找其它地方同名称的库,这样总是首先找到系统原来安装的库,新安装的库不起作用。关键是原来我想,做依赖性检查时,是否能主动找到合适版本的库,后来证实我想错了,操作系统没有那么智能。再有,就是Linux的库,安装后,往往很难卸载,不管是RPM包还是源码包,都很难卸载,在卸载RPM包时,很多依赖的库正在使用某个库而无法下载,如果不知道某个共享库引用了哪些共享库,可以使用ldd命令进行检查,但是别忘了,一个库可能又依赖其它的库,错综复杂,很难卸载。而源码的包,除了直接删除安装目录外,好像没有其它方法,但是对于已经安装的库文件来说,在lib中很难说清楚需要删除哪些库文件。后来解决的办法是直接覆盖原来低版本的库即可。
    后来在VMWare中安装Linux 8.0,总是提示找不到硬盘,还在解决中, 不知道什么原因。而对于64位的版本,是无法安装在32的操作上的,这样虚拟机也无法解决32位上安装64位操作系统。
    后面这一段时间主要解决red hat linux 8.0和9.0上是否兼容的问题。关键我在想,就算都验证了,找到依赖集,将来能希望用户按照我们提供的依赖集进行安装吗,就算安装能顺利解决吗?能否把程序编译成静态库,但是现在看来好像不行,因为ORB虽然提供后缀是.a的静态库,但是链接时出错,还找不到原因。如果程序在低版本的共享库下编译,让高版本兼容也可以,但是这样程序中使用了线程同步的机制在低版本中不支持,那不采用了也不太好。所以如何解决Linux下依赖集,做好发布不是一件简单的事情了。
    好了,要休息了,等测试完了,再继续把结果告诉大家吧。
 
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

manok

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值