[OE-core] [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"

[Kamble, Nitin A]

> [nitin at 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 at 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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120322/99aa5543/attachment-0002.html>