Re: [arm-gnu] GLIBC_2.7 problems with 2009q3-67

[Maxim Kuvyrkov <maxim@xxxxxxxxxxxxxxxx>]

On 4/19/10 3:33 PM, Robert PINSKER wrote:
> Sample compile line is as follows:
>
> arm-none-linux-gnueabi-gcc -mcpu=cortex-a9 -mfpu=neon
> -mfloat-abi=softfp -DHAVE_socklen_t -O3  -DRUSAGE -DHAVE_uint=1
> -DHAVE_int64_t=1 -DHAVE_pmap_clnt_h -DHAVE_socklen_t -DHAVE_DRAND48
> -DHAVE_SCHED_SETAFFINITY=1   -o ../bin/linux/lat_mem_rd lat_mem_rd.c
> ../bin/linux/lmbench.a -lm
> -Wl,-rpath=/mnt/sd/libc/lib:/mnt/sd/libc/usr/lib
> -Wl,--dynamic-linker=/mnt/sd/libc/lib/ld-linux.so.3
>
> /mnt/sd/libc on the target contains pretty much a complete copy of
> the arm-none-linux-gnueabi/libc directory within the CodeSourcery
> installation.  Certainly all the lib directories are correct.

The build command seems correct, when you compile an executable like 
that you should be able run it directly, without resorting to calling 
ld-linux.so.3.

I suggest you investigate where the segmentation fault comes from.  The 
best way to do that is to drop "-O3" flag and add "-g" flag.  Then run 
start the program with
$ /mnt/sd/libc/usr/lib/bin/gdbserver :1234 ./lat_mem_rf
and connect to it from the host's arm-none-linux-gnueabi-gdb.

Does that give you any clue what the problem is?

--
Maxim Kuvyrkov
CodeSourcery
maxim@xxxxxxxxxxxxxxxx
(650) 331-3385 x724