Missing Shared Object Library

If you find that one of the CHEMKIN programs fails to run at all (no output file produced), the problem is often due to a missing shared object library in the system libraries. You can look for these error messages by looking in the Batch Job Output display from the CHEMKIN user interface or by explicitly running the program from the command line. 

These problems most often show up as a failure in the pre-processing step and/or as the failure of the graphical post-processor to appear. 

Frequently newer versions of linux require compatibility libraries to work with our executables because our executables are built with older versions of compilers to allow the broadest range of operating system versions to be supported.  When installing compatibility libraries, you can use the Linux utilities like yum to install general compatibility libraries onto your system.  If you do not have system admin privileges or want to keep these libraries local to just your Reaction Design product install area(s), you can put the shared object libraries in the bin subdirectory of our product installation area(s).  However, when you use this approach, you will need to reapply these libraries with each new version of our products that you install. 

RedHat Enterprise versions of commonly needed libraries are available from our web site for download. They may be compatible with other Linux distributions such as CentOS, but we have not tested this compatibility. 

IDL 6.3/6.4 workaround (32-bit) for Linux x86 and X86_64 incompatibility with updated libX11.so.6 file (.tar) 1,020 KB
Standard C++ shared object libraries, often missing - Redhat 5,32-bit (.gz) 217 KB
Readme for adding shared object libraries to run CHEMKIN on Linux 2.6 core libraries (html) 1 KB
Readme for workaround for Linux (32-bit) for incompatibility with libX11.so.6 (.html) 1 KB
Workaround for Linux (64-bit) for incompatibility with libX11.so6 1 MB
IDL 6.3/6.4 workaround (64-bit) for Linux x86 and X86_64 incompatibility - updated libXp.so.6 file (.tar.gz) 15 KB
IDL 6.3/6.4 workaround (64-bit) for Linux x86 and X86_64 incompatibility - updated libg2c.so.0 file (.tar.ga) 53 KB
IDL 6.3/6.4 workaround (64-bit) for Linux x86 and X86_64 incompatibility - updated libgstdc__.so.5 file (.tar.ga) 217 KB
IDL 6.3/6.4 workaround (64-bit) for Linux x86 and X86_64 incompatibility - updated libg2c.so.0 file (.tar.ga) 1 KB
Readme for workaround for Linux (64-bit) for incompatibility with libX11.so6 (.html) 1 KB
Readme for workaround for Linux (32-bit) for incompatibility with libXp.so6 (.html) 1 KB

The use of the "ldd" command is the best way to explore what shared objects are not found on your system (using the $LD_LIBRARY_PATH search path). Be sure to first "source" our environment setup script so our own libraries are located and explored. 


Our executables are typically compiled and linked using Intel C/C++ and FORTRAN compilers and runtime libraries. See our web download pages for the specific compiler versions used for the product version(s) you install. 

The issues involved in getting applications built on the earlier Linux core to run on the newer Linux core typically involve a combination of installing compatibility packages and/or obtaining individual shared object libraries. We can provide you with specific individual runtime libraries in some cases, such as libg2.so.0, but you may need to also work with the o/s vendor to obtain complete compatibility packages. The first step is to accurately diagnose what libraries are missing using the steps below. 

HOW TO TROUBLESHOOT 


In our experience supporting customers, every "linux installation" is different because there are some many flavors and versions of linux and because there are some many options for which packages to install. Added to this, people typically update their linux installations by adding packages and updating packages so even a consistent beginning installation can become a set of divergent configurations depending on which applications have been subsequently installed. Therefore, the troubleshooting must be performed on each machine. Fortunately, we have found some consistent patterns of missing libraries. 

The most useful command for troubleshooting is the "ldd" command (list dynamic dependencies) that shows the shared libraries needed by an executable or shared object library (.so). What you need to look for is lines that say 
=> not found 
To successfully run this command on CHEMKIN programs and shared objects, you must source the CHEMKIN environment setup script. Compare the results below (I am running with the csh shell): 

$ cd $CHEMKIN_BIN 

$ ldd CKPreProcess 
libCKPreProcess.so => /development/reaction/ck411/chemkin41_linuxx8664/bin/libCKPreProcess.so (0x00002aaaaaaad000) 
libc.so.6 => /lib64/libc.so.6 (0x00000030c4800000) 
libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x00002aaaaada7000) 
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030c5400000) 
libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x00002aaaab083000) 
libm.so.6 => /lib64/libm.so.6 (0x00000030c5000000) 
libxerces-c1_6_0.so => /development/reaction/ck411/chemkin41_linuxx8664/bin/libxerces-c1_6_0.so (0x00002aaaab2a5000)
libckzip.so => /development/reaction/ck411/chemkin41_linuxx8664/bin/libckzip.so (0x00002aaaab5f2000) 
libckunzip.so => /development/reaction/ck411/chemkin41_linuxx8664/bin/libckunzip.so (0x00002aaaab752000) 
/lib64/ld-linux-x86-64.so.2 (0x00000030c4400000) 
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000030c7400000) 

$ ldd aurora 
libaurora.so => /development/reaction/ck411/chemkin41_linuxx8664/bin/libaurora.so (0x00002aaaaaaad000) 
libc.so.6 => /lib64/libc.so.6 (0x00000030c4800000) 
libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x00002aaaaaf08000) 
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030c5400000) 
libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x00002aaaab1e4000) 
libm.so.6 => /lib64/libm.so.6 (0x00000030c5000000) 
libxerces-c1_6_0.so => /development/reaction/ck411/chemkin41_linuxx8664/bin/libxerces-c1_6_0.so (0x00002aaaab406000)
libckzip.so => /development/reaction/ck411/chemkin41_linuxx8664/bin/libckzip.so (0x00002aaaab753000) 
libckunzip.so => /development/reaction/ck411/chemkin41_linuxx8664/bin/libckunzip.so (0x00002aaaab8b3000) 
/lib64/ld-linux-x86-64.so.2 (0x00000030c4400000) 
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000030c7400000) 

$ ldd idl 
libidl.so.6.2 => ./libidl.so.6.2 (0x00002aaaaaaad000) 
libXp.so.6 => /usr/X11R6/lib64/libXp.so.6 (0x0000003647c00000) 
libXpm.so.4 => /usr/lib64/libXpm.so.4 (0x00000030c7400000) 
libXmu.so.6 => /usr/lib64/libXmu.so.6 (0x00000030c5400000) 
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00000030c6800000) 
libXt.so.6 => /usr/lib64/libXt.so.6 (0x00000030cac00000) 
libSM.so.6 => /usr/lib64/libSM.so.6 (0x00000030c9c00000) 
libICE.so.6 => /usr/lib64/libICE.so.6 (0x00000030c9400000) 
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00000030c6000000) 
librt.so.1 => /lib64/librt.so.1 (0x00000030c8400000) 
libm.so.6 => /lib64/libm.so.6 (0x00000030c5000000) 
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab4ec000) 
libc.so.6 => /lib64/libc.so.6 (0x00000030c4800000) 
libMesaGLU6_2.so.1 => ./libMesaGLU6_2.so.1 (0x00002aaaab707000) 
libMesaGL6_2.so.1 => ./libMesaGL6_2.so.1 (0x00002aaaab82b000) 
libOSMesa6_2.so.6 => ./libOSMesa6_2.so.6 (0x00002aaaabb8b000) 
libfreetype2_1_3.so.6 => ./libfreetype2_1_3.so.6 (0x00002aaaabc94000) 
libdl.so.2 => /lib64/libdl.so.2 (0x00000030c4c00000) 
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00000030c5c00000) 
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00000030c6400000) 
/lib64/ld-linux-x86-64.so.2 (0x00000030c4400000) 



Unfortunately, you will discover this can be an iterative process in which each library you copy over reveals that it has other dependencies.