|
From: <kha...@he...> - 2004-10-12 17:25:19
|
I get the following error from valgrind:
==13322== Valgrind detected that your program requires
==13322== the following unimplemented functionality:
==13322== clone(): not supported by Valgrind.
We do now support programs linked against
libpthread.so, though. Re-run with -v and ensure that
you are picking up Valgrind's implementation of libpthread.so.
Rerunning with -v shows that I am indeed not getting valgrind's
libpthread, but /lib/tls/libpthread-0.61.so. How do I get it to use
the correct library?
I have installed valgrind in a nonstandard directory (with the
--prefix configure switch); could this be the problem?
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: <kha...@he...> - 2004-10-12 17:38:51
|
In case it's relevant: this is on a Fedora Core 2 system, with kernel
2.6.6.
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Tom H. <th...@cy...> - 2004-10-12 18:05:22
|
In message <20041012172514.GA11829@malin>
kha...@he... wrote:
> I get the following error from valgrind:
>
> ==13322== Valgrind detected that your program requires
> ==13322== the following unimplemented functionality:
> ==13322== clone(): not supported by Valgrind.
> We do now support programs linked against
> libpthread.so, though. Re-run with -v and ensure that
> you are picking up Valgrind's implementation of libpthread.so.
>
> Rerunning with -v shows that I am indeed not getting valgrind's
> libpthread, but /lib/tls/libpthread-0.61.so. How do I get it to use
> the correct library?
It should use it automatically. One thing that might cause a problem
is having an rpath set in your executable - what does "objdump -p" say
about your program?
> I have installed valgrind in a nonstandard directory (with the
> --prefix configure switch); could this be the problem?
So long as you give the correct prefix when you configure and build
valgrind you should be fine. If you install somewhere other than where
you told valgrind at configure time then you will break things.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Karl <kh...@tr...> - 2004-10-13 09:11:33
|
On 2004-10-12 19:05:39 +0100, Tom Hughes wrote:
> In message <20041012172514.GA11829@malin>
> kha...@he... wrote:
>
> > I get the following error from valgrind:
> >
> > ==13322== Valgrind detected that your program requires
> > ==13322== the following unimplemented functionality:
> > ==13322== clone(): not supported by Valgrind.
> > We do now support programs linked against
> > libpthread.so, though. Re-run with -v and ensure that
> > you are picking up Valgrind's implementation of libpthread.so.
> >
> > Rerunning with -v shows that I am indeed not getting valgrind's
> > libpthread, but /lib/tls/libpthread-0.61.so. How do I get it to
> > use the correct library?
>
> It should use it automatically. One thing that might cause a problem
> is having an rpath set in your executable - what does "objdump -p"
> say about your program?
RPATH /home/kha/local/lara.hq.vtech/lib:/home/kha/local/generic/lib:/usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib
which is exactly the same as my $LD_LIBRARY_PATH. Valgrind is
installed in /home/kha/local/lara.hq.vtech, which means that the full
path to the library is
/home/kha/local/lara.hq.vtech/lib/valgrind/libpthread.so.
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Tom H. <th...@cy...> - 2004-10-13 09:46:52
|
In message <20041013091016.GA6518@malin>
Karl Hasselström <kh...@tr...> wrote:
> On 2004-10-12 19:05:39 +0100, Tom Hughes wrote:
>
>> It should use it automatically. One thing that might cause a problem
>> is having an rpath set in your executable - what does "objdump -p"
>> say about your program?
>
> RPATH
> /home/kha/local/lara.hq.vtech/lib:/home/kha/local/generic/lib:/usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib
>
> which is exactly the same as my $LD_LIBRARY_PATH. Valgrind is
> installed in /home/kha/local/lara.hq.vtech, which means that the full
> path to the library is
> /home/kha/local/lara.hq.vtech/lib/valgrind/libpthread.so.
The RPATH is your problem - you have /lib in there so the libpthread
in /lib will be found via the RPATH before LD_LIBRARY_PATH is searched
which is what would locate the valgrind version.
The way things are supposed to work is that valgrind adds it's own
library directory to LD_LIBRARY_PATH before starting the client
program so that the valgrind pthread library is found. Unfortunately
because RPATH takes priority over LD_LIBRARY_PATH (see man ld.so for
the search rules) the system one is being found first.
It's highly unusual to add the system library directories to the
RPATH in that way - normally you just add any special directories that
your program needs and let the system do it's default stuff to find
the system libraries.
I would suggest that you either drop the system libraries from RPATH,
use RUNPATH instead of RPATH, or add the valgrind library directory to
the RPATH so that valgrind pthread library is found.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Karl <kh...@tr...> - 2004-10-13 09:49:00
|
On 2004-10-13 11:10:16 +0200, Karl Hasselström wrote:
> On 2004-10-12 19:05:39 +0100, Tom Hughes wrote:
>
> > In message <20041012172514.GA11829@malin>
> > kha...@he... wrote:
> >
> > > I get the following error from valgrind:
> > >
> > > ==13322== Valgrind detected that your program requires
> > > ==13322== the following unimplemented functionality:
> > > ==13322== clone(): not supported by Valgrind.
> > > We do now support programs linked against
> > > libpthread.so, though. Re-run with -v and ensure that
> > > you are picking up Valgrind's implementation of libpthread.so.
> > >
> > > Rerunning with -v shows that I am indeed not getting valgrind's
> > > libpthread, but /lib/tls/libpthread-0.61.so. How do I get it to
> > > use the correct library?
> >
> > It should use it automatically. One thing that might cause a problem
> > is having an rpath set in your executable - what does "objdump -p"
> > say about your program?
>
> RPATH /home/kha/local/lara.hq.vtech/lib:/home/kha/local/generic/lib:/usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib
>
> which is exactly the same as my $LD_LIBRARY_PATH. Valgrind is
> installed in /home/kha/local/lara.hq.vtech, which means that the
> full path to the library is
> /home/kha/local/lara.hq.vtech/lib/valgrind/libpthread.so.
I stripped those first two paths (/home/kha/local/lara.hq.vtech/lib
and /home/kha/local/generic/lib) from my LD_LIBRARY_PATH, LIBRARY_PATH
and LD_RUN_PATH, rebuilt everything, and got an RPATH of
/usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib. For some unfathomable
reason, this caused the program to use /lib/i686/libpthread-0.10.so
instead of /lib/tls/libpthread-0.61.so, and valgrind worked. It still
doesn't use valgrind's libpthread.so, but apparently
/lib/i686/libpthread-0.10 is nice enough.
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Tom H. <th...@cy...> - 2004-10-13 10:22:52
|
In message <20041013094849.GB6518@malin>
Karl Hasselström <kh...@tr...> wrote:
> I stripped those first two paths (/home/kha/local/lara.hq.vtech/lib
> and /home/kha/local/generic/lib) from my LD_LIBRARY_PATH, LIBRARY_PATH
> and LD_RUN_PATH, rebuilt everything, and got an RPATH of
> /usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib. For some unfathomable
> reason, this caused the program to use /lib/i686/libpthread-0.10.so
> instead of /lib/tls/libpthread-0.61.so, and valgrind worked. It still
> doesn't use valgrind's libpthread.so, but apparently
> /lib/i686/libpthread-0.10 is nice enough.
That shouldn't work - the i686 libpthread will use clone just as much
as the tls one will. You really need the valgrind one.
The selection between the i686 and tls versions should be triggered by
the setting of LD_ASSUME_KERNEL.
I don't understand where that RPATH setting in the binary is coming
from though if you don't have those directories in LD_RUN_PATH and
aren't using linker command line options to set it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Karl <kh...@tr...> - 2004-10-13 10:56:44
|
On 2004-10-13 11:22:24 +0100, Tom Hughes wrote:
> That shouldn't work - the i686 libpthread will use clone just as
> much as the tls one will. You really need the valgrind one.
Then I guess that the messages I'm seeing about
/lib/i686/libpthread-0.10.so must be mistaken, or something. :-P
> I don't understand where that RPATH setting in the binary is coming
> from though if you don't have those directories in LD_RUN_PATH and
> aren't using linker command line options to set it.
They are in my LD_RUN_PATH . . . or were -- see my last post. I just
figured out that this is the culprit (by adding unique nonexisting
directories to each of LD_RUN_PATH, LD_LIBRARY_PATH, and LIBRARY_PATH,
and seeing which showed up in RPATH).
It seems that the bug here is my reckless trial-and-error use of
linker environment variables. I have yet to find a decent tutorial for
these . . . is there a decent Linking for Dummies somewhere out there?
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Karl <kh...@tr...> - 2004-10-13 10:28:35
|
On 2004-10-13 10:45:48 +0100, Tom Hughes wrote:
> The RPATH is your problem - you have /lib in there so the libpthread
> in /lib will be found via the RPATH before LD_LIBRARY_PATH is
> searched which is what would locate the valgrind version.
>
> The way things are supposed to work is that valgrind adds it's own
> library directory to LD_LIBRARY_PATH before starting the client
> program so that the valgrind pthread library is found. Unfortunately
> because RPATH takes priority over LD_LIBRARY_PATH (see man ld.so for
> the search rules) the system one is being found first.
>
> It's highly unusual to add the system library directories to the
> RPATH in that way - normally you just add any special directories
> that your program needs and let the system do it's default stuff to
> find the system libraries.
>
> I would suggest that you either drop the system libraries from
> RPATH, use RUNPATH instead of RPATH, or add the valgrind library
> directory to the RPATH so that valgrind pthread library is found.
Yes, it works now! Thanks a lot!
What I did was I dropped /usr/lib and /lib from my LD_LIBRARY_PATH,
LIBRARY_PATH and LD_RUN_PATH. Now all I have to do is figure out
exactly which of them is being used for RPATH by the build system . . .
but I won't bore you with that problem. Thanks again!
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Tom H. <th...@cy...> - 2004-10-13 11:15:41
|
In message <20041013102826.GC6518@malin>
Karl Hasselström <kh...@tr...> wrote:
> What I did was I dropped /usr/lib and /lib from my LD_LIBRARY_PATH,
> LIBRARY_PATH and LD_RUN_PATH. Now all I have to do is figure out
> exactly which of them is being used for RPATH by the build system . . .
> but I won't bore you with that problem. Thanks again!
It's LD_RUN_PATH that controls the RPATH setting in the binary.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-10-13 10:59:06
|
On Wed, 13 Oct 2004, Karl Hasselstr=F6m wrote: >> I would suggest that you either drop the system libraries from >> RPATH, use RUNPATH instead of RPATH, or add the valgrind library >> directory to the RPATH so that valgrind pthread library is found. > > Yes, it works now! Thanks a lot! How many times has this RPATH problem come up? Is it worth an entry in=20 the FAQ? Even better, is there a way we can auto-detect and deal with it? N |
|
From: Tom H. <th...@cy...> - 2004-10-13 11:43:07
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> How many times has this RPATH problem come up? Is it worth an entry
> in the FAQ? Even better, is there a way we can auto-detect and deal
> with it?
I'm not aware of it having come up before but it might have done.
Given that we are acting as the ELF loader we ought to be able to
detect it - you just need to look for a DT_RPATH entry in the dynamic
attributes in the ELF file. I don't think we can do anything other
than warn however as it would require altering the ELF headers...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|