测试CORBA

     这两天做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下依赖集，做好发布不是一件简单的事情了。

    好了，要休息了，等测试完了，再继续把结果告诉大家吧。