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.

Logged In: YES 
user_id=21627

This is fixed with 73017 patch in

configure 1.393
configure.in 1.404