|
From: Davis F. <dav...@gm...> - 2013-07-18 21:00:07
|
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 |
|
From: Tom H. <to...@co...> - 2013-07-18 21:22:33
|
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/ |
> 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. |
|
From: Davis F. <dav...@gm...> - 2013-07-22 00:35:57
|
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. > |