Platform: Redhat 7.3 on Intel Xeon Packages involved: valgrind-1.9.5 (http://developer.kde.org/~sewardj/) Python CVS snapshot Thu Apr 24 10:00:00 PDT 2003 valgrind python fails with the following message: % valgrind python python: relocation error: /lib/librt.so.1: symbol __pthread_clock_settime, version GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference This is with: % python Python 2.3b1 (#1, Apr 24 2003, 10:20:26) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> I observed the same problem with Python 2.3a2. There are no problems when using Python 2.2.1 on the exact same platform with the same valgrind installation.
Logged In: YES user_id=33168 I think I got around this problem by adding: void __pthread_clock_settime() { } I think this may be mentioned in the valgrind FAQ/doc. Or perhaps, it's something similar which I am confusing.
Logged In: YES user_id=4771 This is documented as a known problem with the librt.so library on http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt. What I cannot understand is the purpose of binding against that library on Linux. It ends up in the Makefile for some indirect reason. I tried without it and the 'make test' works just fine. Is it worth any further investigation ? If not, close this bug track.
Logged In: YES user_id=71407 > Is it worth any further investigation ? If not, close this > bug track. valgrind is extremely useful. It seems very important to me that Python 2.3 works with valgrind out-of-the-box, just like Python 2.2 does. I'm afraid otherwise "Why doesn't Python work with valgrind?" is going to wind up in the Python FAQ. > What I cannot understand is the purpose of binding against > that library on Linux. It ends up in the Makefile for some > indirect reason. I tried without it and the 'make test' > works just fine. I'd be very glad if you could find ways of not binding against librt.so if it is not needed.
Logged In: YES user_id=4771 I figured it out. 'configure.in' now looks in various libraries for the sem_init() function (it is in different libs on different platforms); more precisely, it searches in librt and libposix4. However, on Linux, for some reason it is also defined in libpthread which is always linked with Python (unless one disables threads, of course). As a suggested fix, I'd say that configure.in should first look for sem_init in libpthread. That way, the Linux compilation won't be linked against the unneeded and valgrind-conflicting librt at all. I can provide a patch that does this.
