When Python shows you where the shared object is and says it doesn't exist

We had this error and it was driving me crazy:

    ImportError: [/.../..]/python2.4/lib/python2.4/lib-dynload/datetime.so: cannot open shared object file: No such file or directory
    [01,003839]PYTHON Error : Undefined Python Module :

When I did an ls for that directory, the shared object was in fact there.  It didn't even help to move the shared object into the same directory as my code.  I googled and looked on the python.org website and couldn't find any other mention of it.  That is, besides making sure the python path and load path were set and that the .so was executable, but that didn't solve the problem.

It turned out that the problem was that calls to the python module were embedded in a larger C program that had compiled and linked pointing to a 32-bit version of python2.4.  But the script that was trying to run the compiled code was pointing to a 64-bit version of python2.4.

Make sure all your python symbolic links are pointing to the same python.

To see if this is your problem, run the Linux "file" command on the .so and on the c-executable that's linked to the python module that's importing the .so.

 $file /[..]/python2.4/lib/python2.4/lib-dynload/datetime.so
/[..]/python2.4/lib/python2.4/lib-dynload/datetime.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped

$file cpgm
cpgm: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped

To solve this, re-compile cpgm in 64 bits, or point to the 32-bit version of python to run it.

$ file cpgm
cpgm: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped

You can get into this trouble on a 64-bit machine or VM since it will run 32-bit compiled code (whereas a 32-bit machine won't run 64-bit compiled code.)