How do I satisfy a 3rd-party shared library reference to stat when I'm creating a shared library shim rather than an executable?

Question

I am the new maintainer for an in-house Python system that uses a set of 3rd-party shared C libraries via a shared library shim that is created using a combination of swig and a setup.py script. This has been working well until recently.

The 3rd-party shared C libraries were updated for new functionality and now I get the following run-time error, after a clean build, when I try to run our main Python program (which imports the generated shared library shim):

-sh-3.00$ python ams.py

ImportError: /usr/lib/libz4lnx.so: undefined symbol: stat

I found a discussion thread from 1999 that explains that the problem is that stat is not present in libc.so.6, but rather in libc_nonshared.a, and provides a solution: Link against the c library, by adding -lc to your build command line.

http://www.redhat.com/archives/pam-list/1999-February/msg00082.html

I've added 'c' to the list of libraries in the setup.py script, but this doesn't change my results. I suspect that this is because I am creating a shared library shim rather than an executable.

How can I satisfy the 3rd-party shared library's reference to stat, given my build environment?

My build system is:

-sh-3.00$ lsb_release -a

LSB Version:    :core-3.0-ia32:core-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch
Distributor ID: CentOS
Description:    CentOS release 4.6 (Final)
Release:        4.6
Codename:       Final

My gcc version is:

-sh-3.00$ gcc --version

gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-10)

My Python version is:

-sh-3.00$ python -V

Python 2.3.4

Answer 1

The solution was to create to a new Centos 5.3 VM and re-build and/or re-install components as needed.

Answer 2

As it turns out, while moving to Centos 5.3 was probably a good thing in the long run, the actual problem turns out to have been the way that libz4lnx was built on the DVD that I was originally using. In the process of moving to Centos 5.3, I also moved to a newer build of the libz4lnx library. Today, while testing something else, I used the library from the original DVD and got the exact same undefined symbol error when running the Python program. Switching back to the newest DVD (some two months newer) solved the problem again.