> [nitin@nbuild0 oecore-x86_64]$
> ./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
> *** glibc detected ***
> ./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb:
> double free or corruption (out): 0x00007f3226818030 ***
> Aborted (core dumped)
> [nitin@nbuild0 oecore-x86_64]$ ldd
> ./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
> linux-vdso.so.1 => (0x00007fffd05d8000)
> libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003f07400000)
> libdl.so.2 =>
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2
> (0x00007fa207a72000)
> libncurses.so.5 =>
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5
> (0x00007fa20784f000)
> libtinfo.so.5 =>
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5
> (0x00007fa207628000)
> libz.so.1 => /lib64/libz.so.1 (0x0000003f06c00000)
> libm.so.6 =>
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6
> (0x00007fa2073a5000)
> libpthread.so.0 =>
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0
> (0x00007fa207188000)
> libutil.so.1 =>
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1
> (0x00007fa206f84000)
> libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003f09800000)
> libc.so.6 =>
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6
> (0x00007fa206bfd000)
>
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2
> => /lib64/ld-linux-x86-64.so.2 (0x0000003f05000000)
>
>
> I am seeing that the sdk gdb is dynamically linking with some of the host
> libraries as seen above.
>
I think host libs is issue here
Why is libexpat libreadline libz being used from build host
I think there are multiple issues here. You are right about the incorrect
dynamic linking with host libraries. If I run the nativesdk on the build
machine, then I don’t see these linking issues, but still gdb core dumps:
$ ldd ./x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
linux-vdso.so.1 => (0x00007fff4b3f2000)
libreadline.so.6 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libreadline.so.6
(0x00007f71c8336000)
libdl.so.2 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2
(0x00007f71c8132000)
libncurses.so.5 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5
(0x00007f71c7f0f000)
libtinfo.so.5 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5
(0x00007f71c7ce8000)
libz.so.1 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libz.so.1
(0x00007f71c7ad3000)
libm.so.6 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6
(0x00007f71c7851000)
libpthread.so.0 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0
(0x00007f71c7634000)
libutil.so.1 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1
(0x00007f71c7431000)
libexpat.so.1 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libexpat.so.1
(0x00007f71c7208000)
libc.so.6 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6
(0x00007f71c6e81000)
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2
(0x00007f71c8576000)
$ ./x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
*** glibc detected ***
./x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb: double free
or corruption (out): 0x00007f1eaf7f4030 ***
Actually we noticed that Eric’s working sdk gdb was getting linked with the
host libpython.so, And if it is linked with the sdk libpython.so then he is
able to see same issue what I am seeing.
So look like issue is in the generated libpython.so.
And in failing case, somehow ldd is not reporting that sdk gdb is dynamically
linked with libpython.so. That is also strange.
Thanks,
Nitin
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
