|
From: Naveen K. <g_n...@ya...> - 2009-05-11 13:22:56
|
Bart
I did some more testing and that LDFLAGS="-L$(TARGET_LIB_PATH)" was the culprit. I removed that for the cross compilation and valgrind starts up fine on target now. Just FYI I did nm on the new executable and there are still undefined symbols
U __assert_fail@@GLIBC_2.0
U __ctype_b_loc@@GLIBC_2.3
U __errno_location@@GLIBC_2.0
U __libc_start_main@@GLIBC_2.0
U access@@GLIBC_2.0
U close@@GLIBC_2.0
U execve@@GLIBC_2.0
U exit@@GLIBC_2.0
U fprintf@@GLIBC_2.0
U fputc@@GLIBC_2.0
U fwrite@@GLIBC_2.0
U getenv@@GLIBC_2.0
U malloc@@GLIBC_2.0
U memcmp@@GLIBC_2.0
U memcpy@@GLIBC_2.0
U memset@@GLIBC_2.0
U mmap@@GLIBC_2.0
U munmap@@GLIBC_2.0
U open@@GLIBC_2.0
U readlink@@GLIBC_2.0
U sprintf@@GLIBC_2.0
U strcat@@GLIBC_2.0
U strchr@@GLIBC_2.0
U strcpy@@GLIBC_2.0
U strerror@@GLIBC_2.0
U strlen@@GLIBC_2.0
U strncmp@@GLIBC_2.0
U sysconf@@GLIBC_2.0
U vfprintf@@GLIBC_2.0
Naveen
----- Original Message ----
From: Bart Van Assche <bar...@gm...>
To: g_n...@ya...
Cc: val...@li...
Sent: Monday, May 11, 2009 2:24:20 AM
Subject: Re: [Valgrind-developers] cross compiling valgrind
On Sat, May 9, 2009 at 9:53 PM, <g_n...@ya...> wrote:
> I understand the logic behind the --prefix option. I am purposely running the valgrind
> executable off of a different path to test if it atleast gives the "unable to locate memcheck
> library" error. After that passes that then I will copy/link directly on target. I will try the
> command that you suggest and check if valgrind is linked properly. Thanks for the info.
Something else you could check is whether there are any undefined
symbols in the Valgrind executable (nm ... | grep ' U '). To my
surprise, I noticed yesterday that it is possible on PPC to create
executables that contain an undefined symbol. When starting such an
executable the result is a segmentation fault.
Bart.
|