Infrastructure Software

Although 11g has been officially certified for RHEL5/OEL5, seems that vice versa is not true: RHEL5/OEL5 has not been certified for 11g yet. It has been true for 5.0, 5.1 and now 5.2.

For 11g to function properly, the LD_LIBRARY_PATH env variable must include 11g lib directory. Also, the same directory must be included in the ld.so.conf (=> ld.so.cache), so that oracle binaries can find shared libraries. When Oracle 11g is installed, the ${ORACLE_HOME}/lib/libexpat.so.0, that is not of the same version as system's libexpat, is the first one automatically picked by ldconfig:

[root@localhost ~]# ldconfig -p | grep libexpat
libexpat.so.0 (libc6) => /opt/oracle/product/11.1.0/db_1/lib/libexpat.so.0
libexpat.so.0 (libc6) => /lib/libexpat.so.0
libexpat.so (libc6) => /opt/oracle/product/11.1.0/db_1/lib/libexpat.so
libexpat.so (libc6) => /usr/lib/libexpat.so

Now, when I start gedit, my favourite gui editor, it segfaults and doesn't start at all. Why?

[root@localhost ~]# ldd /usr/bin/gedit | grep libexpat
libexpat.so.0 => /opt/oracle/product/11.1.0/db_1/lib/libexpat.so.0 (0x00b16000)

Because gedit has been linked against system's libexpat that obviously is not of the same version as libexpat shipped with 11g. So, I had to delete 11g expat libraries and make symlinks to system's libraries. Now gedit and 11g works fine as always.

I didn't want to report this in the 5.0/5.1 hoping that oracle linux folks would solve this discrepancy. This time, however, I couldn't resist.