valgrind-users

[Valgrind-users] Statically compiling Valgrind

[Davis F. <dav...@gm...>]

Hi, I'm interested in the same request as this user:
http://thread.gmane.org/gmane.comp.debugging.valgrind/9322/focus=9323

I have a piece of hardware running Linux that does support shared objects,
but the OS is heavily modified, and it lacks several shared objects in
standard places.  It also lacks a compiler along with a lot of other useful
tools.  Building on the target is not an option, so I'd have to
cross-compile.

However, it so happens that this target is binary compatible with the
Raspberry Pi, and I am able to build executables on the Pi with -static and
run them on this other target.  If I compile without -static, it usually
always fails b/c the .so files are missing or in non-standard places.  At
boot it explodes most of the filesystem to a ramdisk that is read only.
 Instead of trying to hack around all this -- the easiest thing to do is
just build with -static.

I have a binary for valgrind on the Pi, and the ldd output is:

/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x401dc000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x400d3000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x401e5000)
/lib/ld-linux-armhf.so.3 (0x40011000)

Is there an easy way I can tweak the build files to statically link these
libraries?  Are there any other tools the valgrind executable depends on
that I also need to build to make it work?

Regards,
Davis

Re: [Valgrind-users] Statically compiling Valgrind

[Tom H. <to...@co...>]

On 18/07/13 21:59, Davis Ford wrote:

> I have a binary for valgrind on the Pi, and the ldd output is:
>
> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x401dc000)
> libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x400d3000)
> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x401e5000)
> /lib/ld-linux-armhf.so.3 (0x40011000)

That's just the launcher which selects which tool binary to use. The 
real programs that do the work are the tools in the library directory 
and are already statically linked.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Statically compiling Valgrind

[John R. <jr...@Bi...>]

> I have a binary for valgrind on the Pi, and the ldd output is:
>
> /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x401dc000)
> libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x400d3000)
> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x401e5000)
> /lib/ld-linux-armhf.so.3 (0x40011000)
>
> Is there an easy way I can tweak the build files to statically link these libraries?  Are there any other tools the valgrind executable depends on that I also need to build to make it work?

The top-level Makefile for valgrind looks somewhat ordinary.  So you could try
adding "-static  -static-libgcc" to to CFLAGS.  (Or add "-static" to LDFLAGS,
or add "-Wl,-static" to CFLAGS.)  Then look at the final link command: invoke
'make' and observe the commands that are displayed on stderr.  In the worst
case, then run under "strace -f -o strace.out -e trace=execve make ..." then
inspect strace.out to find the actual process command line.  Also look at the
output from ldd, to see how well those attempts worked.  You might also look
one level down at memcheck/Makefile, but CFLAGS etc. from the top-level
Makefile should propagate to the individual tools such as memcheck.

Re: [Valgrind-users] Statically compiling Valgrind

[Davis F. <dav...@gm...>]

Thanks John / Tom -- I aim to try that out.  Regards, Davis

On Sun, Jul 21, 2013 at 6:58 PM, John Reiser <jr...@bi...> wrote:

> The top-level Makefile for valgrind looks somewhat ordinary.  So you could
> try
> adding "-static  -static-libgcc" to to CFLAGS.  (Or add "-static" to
> LDFLAGS,
> or add "-Wl,-static" to CFLAGS.)  Then look at the final link command:
> invoke
> 'make' and observe the commands that are displayed on stderr.  In the worst
> case, then run under "strace -f -o strace.out -e trace=execve make ..."
> then
> inspect strace.out to find the actual process command line.  Also look at
> the
> output from ldd, to see how well those attempts worked.  You might also
> look
> one level down at memcheck/Makefile, but CFLAGS etc. from the top-level
> Makefile should propagate to the individual tools such as memcheck.
>