Ashley Pittman <apittman <at> concurrent-thinking.com> writes:
> On Mon, 2008-04-28 at 13:16 +0200, Julian Seward wrote:
> > On Monday 28 April 2008 13:10, Christian Keil wrote:
> > > > I had to compile Valgrind source code on a different host because I do
> > > > not have any compilation tools installed on my production host.
> > > >
> > > > I thought of using "-prefix=<Install-dir-path>" while doing
> > > > "./configure".
> > > >
> > > > But I cannot do that also because the directory structure on
> > > > production
> > > > host is totally different than development host (this is because user
> > > > logins are different).
> > >
> > > This is the scenario that DESTDIR is made for. Configure Valgrind
> > > exactly like you would do it when building on your production machine
> > > (i.e., use the prefix from that machine), make all, and then
> > >
> > > $ make install DESTDIR=temporary/install/prefix
> > >
> > > This way make will compile the correct paths into the library but copy
> > > the files to <temporary/install/prefix/...> from where you can just copy
> > > everything to your production machine.
> > Sounds good, but do you know if this really works with Valgrind?
> > I'm sure we "bake in" some paths at build time.
> Surely this would be a bug then ;) As long as the baked in paths are
> what was given to configure it should work just fine. Granted the
> install might not work from DESTDIR but once copied to the prefix dir it
There is an environment variable called VALGRIND_LIB
This can be set to point to teh base directory of where the tools are.
Valgrind do not document the workaround very well imho
For my cluster:
==15928== Memcheck, a memory error detector.
==15928== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==15928== Using LibVEX rev 1884, a library for dynamic binary translation.
==15928== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
Hope this helps,