fix for the sdk gdb issue
cover fix for the sdk gdb issue
From: Nitin A Kamble <[email protected]>
This reverts the commit for adding python support to sdk gdb. It is breaking the sdk gdb as reported in this bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2077
The following changes since commit 40f95685e6a3b4359d2ab2fea1418fe5e4bd0aa1:
gzip/pigz-native: Install into a prefix to avoid clashing with system binaries (2012-03-21 15:33:07 +0000)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib nitin/bugfix
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/bugfix
Nitin A Kamble (1):
Revert "gdb-cross-canadian: build gdb with python support"
meta/recipes-devtools/gdb/gdb-cross-canadian.inc | 20 +------------------- .../recipes-devtools/gdb/gdb-cross-canadian_7.4.bb | 2 +- 2 files changed, 2 insertions(+), 20 deletions(-)
Signature · 1 line
1.7.6.4
PATCH 1/1 Revert "gdb-cross-canadian: build gdb with python support"
From: Nitin A Kamble <[email protected]>
This reverts commit 1cb4614f1d5e482b88ea372d1841a6c313a49941.
and bump PR
This fixes this bug:
[YOCTO #2077] - memory buffer mess up of i586-poky-linux-gdb in meta-toolchain
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2077
--- meta/recipes-devtools/gdb/gdb-cross-canadian.inc | 20 +------------------- .../recipes-devtools/gdb/gdb-cross-canadian_7.4.bb | 2 +- 2 files changed, 2 insertions(+), 20 deletions(-)
meta/recipes-devtools/gdb/gdb-cross-canadian.inc +1 -19
@@ -4,22 +4,4 @@ DESCRIPTION = "cross-canadian gdb for ${TARGET_ARCH} target - GNU debugger" PN = "gdb-cross-canadian-${TRANSLATED_TARGET_ARCH}" BPN = "gdb" -DEPENDS = "ncurses-nativesdk expat-nativesdk gettext-nativesdk readline-nativesdk python-nativesdk" -RDEPENDS += "python-nativesdk-core python-nativesdk-lang python-nativesdk-re \ - python-nativesdk-codecs python-nativesdk-netclient" - -EXTRA_OECONF_append = "--with-python=${WORKDIR}/python" - -do_configure_prepend() { -cat > ${WORKDIR}/python << EOF -#! /bin/sh -case "\$2" in - --includes) echo "-I${STAGING_INCDIR}/python${PYTHON_BASEVERSION}/" ;; - --ldflags) echo "-L${STAGING_LIBDIR}/../python${PYTHON_BASEVERSION}/config -lpthread -ldl -lutil -lm -lpython${PYTHON_BASEVERSION}" ;; - --exec-prefix) echo "/usr" ;; - *) exit 1 ;; -esac -exit 0 -EOF - chmod +x ${WORKDIR}/python -} +DEPENDS = "ncurses-nativesdk expat-nativesdk gettext-nativesdk readline-nativesdk"
meta/recipes-devtools/gdb/gdb-cross-canadian_7.4.bb +1 -1
@@ -1,7 +1,7 @@ require gdb-common.inc require gdb-cross-canadian.inc -PR = "${INC_PR}.3" +PR = "${INC_PR}.4" GDBPROPREFIX = "--program-prefix='${TARGET_PREFIX}'" EXPAT = "--with-expat"
Signature · 1 line
1.7.6.4
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Hi Nitin,
Quoted 10 lines · Le Wed, 21 Mar 2012 09:35:16 -0700, [email protected] a écrit :
From: Nitin A Kamble <[email protected]>
This reverts commit
1cb4614f1d5e482b88ea372d1841a6c313a49941.and bump PR
This fixes this bug:
[YOCTO #2077] - memory buffer mess up of i586-poky-linux-gdb in meta-toolchain
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2077
this configuration should work as python is enabled in gdb in most modern distribution, the problem here may be in the libreadline of the host system.
May you please try to remove --with-system-readline from EXTRA_OECONF in gdb-common.inc so that gdb doesn't try to use the libreadline of your old ubuntu system ?
If that solves the problem this would allow us not to loose this python scripting capability which is quite useful in gdb.
Thanks
Eric
Signature · 1 line
http://eukrea.com/en/news/104-2012
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 34 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 10:08 AM
To: Kamble, Nitin A
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Hi Nitin,
Quoted 8 lines · Le Wed, 21 Mar 2012 09:35:16 -0700, [email protected] a écrit :
From: Nitin A Kamble <[email protected]>
This reverts commit
1cb4614f1d5e482b88ea372d1841a6c313a49941.and bump PR
This fixes this bug:
[YOCTO #2077] - memory buffer mess up of i586-poky-linux-gdb in meta-toolchain
Quoted 2 lines
this configuration should work as python is enabled in gdb in most modern distribution, the problem here may be in the libreadline of the host system.
May you please try to remove --with-system-readline fromEXTRA_OECONFin gdb-common.inc so that gdb doesn't try to use the libreadline of your old ubuntu system ?
Quoted 7 lines
If that solves the problem this would allow us not to loose this python scripting capability which is quite useful in gdb.
Thanks
Eric
--
http://eukrea.com/en/news/104-2012
Hi Eric,
I tried removing the "--with-system-readline" from the EXTRA_OECONF. It did not change the behavior of the issue.
Also I noticed that that commit never worked in the tree. I have built it on fedora and suse systems.
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 2 lines · Nitin A
I tried removing the "--with-system-readline" from the
EXTRA_OECONF. It did not change the behavior of the issue.
Also I noticed that that commit never worked in the tree. I have built it on fedora and suse systems.
it works fine here (Fedora 16 x86_64 host system, oe-core + qemuarm target + meta-toolchain-qte), tested yersterday.
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 13 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 10:52 AM
To: Kamble, Nitin A
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 1 line · Nitin A
I tried removing the "--with-system-readline" from the
Quoted 8 lines
EXTRA_OECONF. It did not change the behavior of the issue.Quoted 1 line
Also I noticed that that commit never worked in the tree. I have
built it on fedora and suse systems.
it works fine here (Fedora 16
x86_64host system, oe-core + qemuarm target + meta-toolchain-qte), tested yersterday.Eric
Can you try meta-toolchain for qemux86 or qemux86-64 machine ?
I found that sdk gdb is failing for these machines since that commit went in the oe-core.
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 3 lines · Nitin A
Can you try meta-toolchain for qemux86 or qemux86-64 machine ?
I found that sdk gdb is failing for these machines since that commit went in the oe-core.
I'm launching a build and will keep you informed of the result. If that only fails for x86 or x86_64 targets, we can use overrides to disable python support only for these targets.
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 15 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 11:02 AM
To: Kamble, Nitin A
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 2 lines · Nitin A
Can you try meta-toolchain for qemux86 or qemux86-64 machine ? I found that sdk gdb is failing for these machines since that commit
Quoted 7 lines
went in the oe-core.
Quoted 1 line
I'm launching a build and will keep you informed of the result. If that only fails for x86 or
x86_64targets, we can use overrides to disable python support only for these targets.Eric
I also starting test for sdk gdb for qemuarm target. Will keep you posted. Any solution that gives a working sdk gdb for all arches will be good.
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Hi Nitin,
Quoted 9 lines · Nitin A
Quoted 6 lines
From: Eric Bénard [mailto:[email protected]]
I'm launching a build and will keep you informed of the result. If that only fails for x86 orx86_64targets, we can use overrides to disable python support only for these targets.Eric
I also starting test for sdk gdb for qemuarm target. Will keep you posted. Any solution that gives a working sdk gdb for all arches will be good.
that works fine here at least for target qemux86 :
[ebenard@eb-e6520 ~]$ cat /etc/fedora-release Fedora release 16 (Verne)
[ebenard@eb-e6520 ~]$ uname -a
Linux eb-e6520 3.2.9-2.fc16.x86_64 #1 SMP Mon Mar 5 20:55:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[ebenard@eb-e6520 ~]$
source /usr/local/oecore-x86_64/environment-setup-i586-oe-linux
[ebenard@eb-e6520 ~]$ which i586-oe-linux-gdb /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/i586-oe-linux/i586-oe-linux-gdb
[ebenard@eb-e6520 ~]$ i586-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-oesdk-linux --target=i586-oe-linux". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python import sys
(gdb) python sys.stdout.write("hello, world\n")
hello, world
(gdb)
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 27 lines · Eric Bénard
Hi Nitin,
Quoted 9 lines · Nitin A
Quoted 6 lines
From: Eric Bénard [mailto:[email protected]]
I'm launching a build and will keep you informed of the result. If that only fails for x86 orx86_64targets, we can use overrides to disable python support only for these targets.Eric
I also starting test for sdk gdb for qemuarm target. Will keep you posted. Any solution that gives a working sdk gdb for all arches will be good.
that works fine here at least for target qemux86 :
[ebenard@eb-e6520 ~]$ cat/etc/fedora-releaseFedora release 16 (Verne)[ebenard@eb-e6520 ~]$ uname -a
Linux eb-e6520 3.2.9-2.fc16.x86_64 #1 SMP Mon Mar 5 20:55:39 UTC 2012x86_64x86_64x86_64GNU/Linux[ebenard@eb-e6520 ~]$
source/usr/local/oecore-x86_64/environment-setup-i586-oe-linux[ebenard@eb-e6520 ~]$ which i586-oe-linux-gdb
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/i586-oe-linux/i586-oe-linux-gdb
Quoted 14 lines
[ebenard@eb-e6520 ~]$ i586-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-oesdk-linux --target=i586-oe-linux". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python import sys
(gdb) pythonsys.stdout.write("hello, world\n")
hello, world
(gdb)
Just retested with qemux86-64 and distroless oe-core and also works
OE @ /usr/local/oecore-i686 $ x86_64-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-oesdk-linux --target=x86_64-oe-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python print 42
42
the same with armv7a (and my normal SHR layers on top of oe-core)
OE @ /usr/local/oecore-i686 $ sysroots/i686-oesdk-linux/usr/bin/armv7a-vfp-neon-oe-linux-gnueabi/arm-oe-linux-gnueabi-gdb GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-oesdk-linux --target=arm-oe-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python print 42
42
And host system is gentoo..
Nitin: please try with distroless oe-core to see if it's host or poky issue (poky still has own SDK_* paths..).
Cheers,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 97 lines
-----Original Message-----
From: Martin Jansa [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 12:49 PM
To: Eric Bénard
Cc: Kamble, Nitin A; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 12 lines · Eric Bénard
Hi Nitin,
Quoted 8 lines · Nitin A
Quoted 6 lines
From: Eric Bénard [mailto:[email protected]] I'm launching a build and will keep you informed of the result. If that only fails for x86 or
x86_64targets, we can use overrides to disable python support only for these targets.Eric
I also starting test for sdk gdb for qemuarm target. Will keep you
posted. Any solution that gives a working sdk gdb for all arches will be good.
Quoted 9 lines
Quoted 1 line
that works fine here at least for target qemux86 :
[ebenard@eb-e6520 ~]$ cat/etc/fedora-releaseFedora release 16 (Verne)[ebenard@eb-e6520 ~]$ uname -a
Linux eb-e6520 3.2.9-2.fc16.x86_64 #1 SMP Mon Mar 5 20:55:39 UTC 2012x86_64x86_64x86_64GNU/LinuxQuoted 5 lines
[ebenard@eb-e6520 ~]$
source/usr/local/oecore-x86_64/environment-setup-i586-oe-linux[ebenard@eb-e6520 ~]$ which i586-oe-linux-gdb
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/i586-oe-l
Quoted 6 lines
inux/i586-oe-linux-gdb
[ebenard@eb-e6520 ~]$ i586-oe-linux-gdb GNU gdb (GDB) 7.4 Copyright
(C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html> This is free software: you arefree
Quoted 2 lines
to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for
details.
Quoted 6 lines
This GDB was configured as "--host=x86_64-oesdk-linux --target=i586-oe-linux". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python import sys
(gdb) pythonsys.stdout.write("hello, world\n")hello, world (gdb)Just retested with qemux86-64 and distroless oe-core and also works
OE @
/usr/local/oecore-i686$ x86_64-oe-linux-gdb GNU gdb (GDB) 7.4 Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-oesdk-linux --target=x86_64-oe- linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python print 42
42the same with armv7a (and my normal SHR layers on top of oe-core)
OE @
/usr/local/oecore-i686$ sysroots/i686-oesdk-linux/usr/bin/armv7a-vfp-neon-oe-linux-gnueabi/arm- oe-linux-gnueabi-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-oesdk-linux --target=arm-oe- linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python print 42
42And host system is gentoo..
Quoted 7 lines
Nitin: please try with distroless oe-core to see if it's host or poky issue (poky still has own SDK_* paths..).
Cheers,
--
Martin 'JaMa' Jansa jabber: [email protected]
Hi Martin,
I removed the meta-yocto layer, which removed poky distro from the config. And I am still seeing same issue.
[nitin@nbuild0 /]$ cd /usr/local/oecore-x86_64/
[nitin@nbuild0 oecore-x86_64]$ ls
environment-setup-x86_64-oe-linux site-config-x86_64-oe-linux sysroots version-x86_64-oe-linux
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux
[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): 0x00007f3221852030 *** Aborted (core dumped)
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 10 lines · Nitin A
I removed the meta-yocto layer, which removed poky distro from the config. And I am still seeing same issue.
[nitin@nbuild0 /]$ cd
/usr/local/oecore-x86_64/
[nitin@nbuild0 oecore-x86_64]$ ls
environment-setup-x86_64-oe-linux site-config-x86_64-oe-linux sysroots version-x86_64-oe-linux
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux
[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):0x00007f3221852030*** Aborted (core dumped)
may you please provide details on :
- log reported by bitbake when you launch it to know a little bit more your configuration,
- host distribution and arch of your build host
Thanks
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 23 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 2:03 PM
To: Kamble, Nitin A
Cc: Martin Jansa; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 1 line · Nitin A
I removed the meta-yocto layer, which removed poky distro from the
config. And I am still seeing same issue.
Quoted 4 lines
[nitin@nbuild0 /]$ cd
/usr/local/oecore-x86_64/[nitin@nbuild0 oecore-x86_64]$ ls environment-setup-x86_64-oe-linux site-config-x86_64-oe-linuxsysroots version-x86_64-oe-linux
Quoted 2 lines
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux
[nitin@nbuild0 oecore-x86_64]$ sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
Quoted 8 lines
Quoted 1 line
*** glibc detected *** sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-
linux/x86_64-oe-linux-gdb: double free or corruption (out):
0x00007f3221852030***Quoted 2 lines
Aborted (core dumped)
may you please provide details on :
- log reported by bitbake when you launch it to know a little bit more your configuration,
This is with yocto git repo, with just meta layer, I removed the meta-yocto layer from configuration to keep just oecore bits and to take out the poky bits.
$ bitbake meta-toolchain Pseudo is not present but is required, building this first before the main build Parsing recipes: 100% |#############################################################################| Time: 00:00:03 Parsing of 831 .bb files complete (0 cached, 831 parsed). 1107 targets, 19 skipped, 0 masked, 0 errors.
OE Build Configuration:
BB_VERSION = "1.15.1" TARGET_ARCH = "x86_64" TARGET_OS = "linux" MACHINE = "qemux86-64" DISTRO = "" DISTRO_VERSION = "oe-core.0" TUNE_FEATURES = "m64" TARGET_FPU = "" meta = "master:40f95685e6a3b4359d2ab2fea1418fe5e4bd0aa1"
Quoted 1 line
- host distribution and arch of your build host
Build host:
$ cat /etc/SuSE-release openSUSE 11.4 (x86_64) VERSION = 11.4 CODENAME = Celadon $ uname -a Linux yocto-hm1 2.6.37.6-0.7-default #1 SMP 2011-07-21 02:17:24 +0200 x86_64 x86_64 x86_64 GNU/Linux
SDK machine host:
$ cat /etc/redhat-release Fedora release 15 (Lovelock) $ uname -a Linux nbuild0.sc.intel.com 2.6.40.6-0.fc15.x86_64 #1 SMP Tue Oct 4 00:39:50 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Next I am also trying to build from the oe-core git tree.
Thanks,
Nitin
Quoted 3 lines
Thanks
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Hi Nitin,
FWIW I took the i586 target sdk generated on the Fedora 16 and put it on a VirtualBox VM running ubuntu 10.04.3 LTS x86_64 (2.6.32 kernel) and gdb still works fine.
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 7 lines
Hi Nitin,
FWIW I took the i586 target sdk generated on the Fedora 16 and put it on a VirtualBox VM running ubuntu 10.04.3 LTS
x86_64(2.6.32 kernel) and gdb still works fine.Eric
Eric,
If it is working for you, I don't understand why is it not working here.
[nitin@nbuild0 oecore-x86_64]$ cd /usr/local/oecore-x86_64/
[nitin@nbuild0 oecore-x86_64]$ ls
environment-setup-x86_64-oe-linux site-config-x86_64-oe-linux sysroots version-x86_64-oe-linux
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux
[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.
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 2 lines · Nitin A
If it is working for you, I don't understand why is it not working here.
it's not working _only_ for me, Martin also had success.
Quoted 22 lines
[nitin@nbuild0 oecore-x86_64]$ cd
/usr/local/oecore-x86_64/
[nitin@nbuild0 oecore-x86_64]$ ls
environment-setup-x86_64-oe-linux site-config-x86_64-oe-linux sysroots version-x86_64-oe-linux
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux
[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-gdblinux-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)
Quoted 2 lines
I am seeing that the sdk gdb is dynamically linking with some of the host libraries as seen above.
ebenard@eb-e6520 x86_64-oe-linux]$ ldd x86_64-oe-linux-gdb
./x86_64-oe-linux-gdb: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version GLIBC_2.14' not found (required by /lib64/libz.so.1) ./x86_64-oe-linux-gdb: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version GLIBC_2.14' not found (required by /usr/lib64/libpython2.7.so.1.0)
linux-vdso.so.1 => (0x00007fff12dff000) libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ba3a00000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007fbfa6c67000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007fbfa6a44000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007fbfa681d000) libz.so.1 => /lib64/libz.so.1 (0x0000003ba3200000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007fbfa659a000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007fbfa637d000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007fbfa6179000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003bb3000000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003ba7200000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007fbfa5df1000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003ba1600000)
[ebenard@eb-e6520 x86_64-oe-linux]$ ./x86_64-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-oesdk-linux --target=x86_64-oe-linux". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
[ebenard@eb-e6520 x86_64-oe-linux]$ cd ../i586-oe-linux/
[ebenard@eb-e6520 i586-oe-linux]$ ldd i586-oe-linux-gdb
./i586-oe-linux-gdb: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version GLIBC_2.14' not found (required by /lib64/libz.so.1) ./i586-oe-linux-gdb: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version GLIBC_2.14' not found (required by /usr/lib64/libpython2.7.so.1.0)
linux-vdso.so.1 => (0x00007fff7c949000) libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ba3a00000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007fe6f9c74000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007fe6f9a51000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007fe6f982a000) libz.so.1 => /lib64/libz.so.1 (0x0000003ba3200000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007fe6f95a7000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007fe6f938a000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007fe6f9186000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003bb3000000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003ba7200000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007fe6f8dfe000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003ba1600000)
[ebenard@eb-e6520 i586-oe-linux]$ ./i586-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-oesdk-linux --target=i586-oe-linux". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
Signature · 1 line
http://eukrea.com/en/news/104-2012
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 142 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 3:05 PM
To: Kamble, Nitin A
Cc: Martin Jansa; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 1 line · Nitin A
If it is working for you, I don't understand why is it not working
here.
Quoted 1 line
it's not working _only_ for me, Martin also had success.
Quoted 3 lines
[nitin@nbuild0 oecore-x86_64]$ cd
/usr/local/oecore-x86_64/[nitin@nbuild0 oecore-x86_64]$ ls environment-setup-x86_64-oe-linux site-config-x86_64-oe-linuxsysroots version-x86_64-oe-linux
Quoted 2 lines
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux [nitin@nbuild0 oecore-x86_64]$ ./sysroots/x86_64-oesdk-
linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
Quoted 1 line
*** glibc detected *** ./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-
oe-linux/x86_64-oe-linux-gdb: double free or corruption (out):
0x00007f3226818030***Quoted 2 lines
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
Quoted 2 lines
linux-vdso.so.1 => (0x00007fffd05d8000) libreadline.so.6 => /lib64/libreadline.so.6(
0x0000003f07400000)Quoted 1 line
libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (
0x00007fa207a72000)Quoted 1 line
libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (
0x00007fa20784f000)Quoted 1 line
libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (
0x00007fa207628000)Quoted 2 lines
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)Quoted 1 line
libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (
0x00007fa207188000)Quoted 1 line
libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (
0x00007fa206f84000)Quoted 2 lines
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)Quoted 1 line
/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)Quoted 3 lines
I am seeing that the sdk gdb is dynamically linking with some of the
host libraries as seen above.
Quoted 1 line
ebenard@eb-e6520 x86_64-oe-linux]$ ldd x86_64-oe-linux-gdb ./x86_64-oe-linux-gdb:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by/lib64/libz.so.1)
./x86_64-oe-linux-gdb:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by/usr/lib64/libpython2.7.so.1.0)linux-vdso.so.1 => (0x00007fff12dff000) libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ba3a00000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libdl.so.2 (0x00007fbfa6c67000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64- oesdk-linux/lib/libncurses.so.5 (0x00007fbfa6a44000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libtinfo.so.5 (0x00007fbfa681d000) libz.so.1 => /lib64/libz.so.1 (0x0000003ba3200000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libm.so.6 (0x00007fbfa659a000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64- oesdk-linux/lib/libpthread.so.0 (0x00007fbfa637d000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libutil.so.1 (0x00007fbfa6179000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003bb3000000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003ba7200000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libc.so.6 (0x00007fbfa5df1000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 =>
/lib64/ld-linux-x86-64.so.2(0x0000003ba1600000) [ebenard@eb-e6520 x86_64-oe-linux]$ ./x86_64-oe-linux-gdb GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-oesdk-linux --target=x86_64-oe-linux". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
[ebenard@eb-e6520 x86_64-oe-linux]$ cd ../i586-oe-linux/[ebenard@eb-e6520 i586-oe-linux]$ ldd i586-oe-linux-gdb ./i586-oe-linux-gdb:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by/lib64/libz.so.1)
./i586-oe-linux-gdb:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by/usr/lib64/libpython2.7.so.1.0)linux-vdso.so.1 => (0x00007fff7c949000) libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ba3a00000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libdl.so.2 (0x00007fe6f9c74000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64- oesdk-linux/lib/libncurses.so.5 (0x00007fe6f9a51000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libtinfo.so.5 (0x00007fe6f982a000) libz.so.1 => /lib64/libz.so.1 (0x0000003ba3200000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libm.so.6 (0x00007fe6f95a7000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64- oesdk-linux/lib/libpthread.so.0 (0x00007fe6f938a000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libutil.so.1 (0x00007fe6f9186000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003bb3000000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003ba7200000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libc.so.6 (0x00007fe6f8dfe000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 =>
/lib64/ld-linux-x86-64.so.2(0x0000003ba1600000) [ebenard@eb-e6520 i586-oe-linux]$ ./i586-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-oesdk-linux --target=i586-oe- linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
Quoted 2 lines
Looks like in my case the sdk gdb is not dynamically linked with libpython.
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Eric, Nitin:
Sorry for the top post here, looks like there might be some difference during configuration and compilation, can you send your config.log and the log.do_configure along with log.do_compile to the list.
I think they need more investigation.
Sau!
Quoted 156 lines · Nitin A
Quoted 142 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 3:05 PM
To: Kamble, Nitin A
Cc: Martin Jansa; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 1 line · Nitin A
If it is working for you, I don't understand why is it not working
here.
Quoted 1 line
it's not working _only_ for me, Martin also had success.
Quoted 3 lines
[nitin@nbuild0 oecore-x86_64]$ cd
/usr/local/oecore-x86_64/[nitin@nbuild0 oecore-x86_64]$ ls environment-setup-x86_64-oe-linux site-config-x86_64-oe-linuxsysroots version-x86_64-oe-linux
Quoted 2 lines
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux [nitin@nbuild0 oecore-x86_64]$ ./sysroots/x86_64-oesdk-
linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
Quoted 1 line
*** glibc detected *** ./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-
oe-linux/x86_64-oe-linux-gdb: double free or corruption (out):
0x00007f3226818030***Quoted 2 lines
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
Quoted 2 lines
linux-vdso.so.1 => (0x00007fffd05d8000) libreadline.so.6 => /lib64/libreadline.so.6(
0x0000003f07400000)Quoted 1 line
libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (
0x00007fa207a72000)Quoted 1 line
libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (
0x00007fa20784f000)Quoted 1 line
libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (
0x00007fa207628000)Quoted 2 lines
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)Quoted 1 line
libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (
0x00007fa207188000)Quoted 1 line
libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (
0x00007fa206f84000)Quoted 2 lines
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)Quoted 1 line
/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)Quoted 3 lines
I am seeing that the sdk gdb is dynamically linking with some of the
host libraries as seen above.
Quoted 1 line
ebenard@eb-e6520 x86_64-oe-linux]$ ldd x86_64-oe-linux-gdb ./x86_64-oe-linux-gdb:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by/lib64/libz.so.1)
./x86_64-oe-linux-gdb:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by/usr/lib64/libpython2.7.so.1.0)linux-vdso.so.1 => (0x00007fff12dff000) libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ba3a00000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libdl.so.2 (0x00007fbfa6c67000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64- oesdk-linux/lib/libncurses.so.5 (0x00007fbfa6a44000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libtinfo.so.5 (0x00007fbfa681d000) libz.so.1 => /lib64/libz.so.1 (0x0000003ba3200000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libm.so.6 (0x00007fbfa659a000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64- oesdk-linux/lib/libpthread.so.0 (0x00007fbfa637d000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libutil.so.1 (0x00007fbfa6179000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003bb3000000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003ba7200000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libc.so.6 (0x00007fbfa5df1000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 =>
/lib64/ld-linux-x86-64.so.2(0x0000003ba1600000) [ebenard@eb-e6520 x86_64-oe-linux]$ ./x86_64-oe-linux-gdb GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-oesdk-linux --target=x86_64-oe-linux". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
[ebenard@eb-e6520 x86_64-oe-linux]$ cd ../i586-oe-linux/[ebenard@eb-e6520 i586-oe-linux]$ ldd i586-oe-linux-gdb ./i586-oe-linux-gdb:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by/lib64/libz.so.1)
./i586-oe-linux-gdb:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by/usr/lib64/libpython2.7.so.1.0)linux-vdso.so.1 => (0x00007fff7c949000) libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ba3a00000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libdl.so.2 (0x00007fe6f9c74000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64- oesdk-linux/lib/libncurses.so.5 (0x00007fe6f9a51000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libtinfo.so.5 (0x00007fe6f982a000) libz.so.1 => /lib64/libz.so.1 (0x0000003ba3200000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libm.so.6 (0x00007fe6f95a7000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64- oesdk-linux/lib/libpthread.so.0 (0x00007fe6f938a000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libutil.so.1 (0x00007fe6f9186000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003bb3000000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003ba7200000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk- linux/lib/libc.so.6 (0x00007fe6f8dfe000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 =>
/lib64/ld-linux-x86-64.so.2(0x0000003ba1600000) [ebenard@eb-e6520 i586-oe-linux]$ ./i586-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-oesdk-linux --target=i586-oe- linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) quitQuoted 2 lines
Looks like in my case the sdk gdb is not dynamically linked with libpython.
Nitin
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Hi Saul,
Quoted 6 lines · Saul Wold
Sorry for the top post here, looks like there might be some difference during configuration and compilation, can you send your config.log and the log.do_configure along with log.do_compile to the list.
I think they need more investigation.
please find attached the two files.
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Eric, Saul,
Gdb-cross-canadian build logs from my build attached.
Nitin
Quoted 24 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 3:37 PM
To: Saul Wold
Cc: Patches and discussions about the oe-core layer; Kamble, Nitin A; Martin Jansa
Subject: Re: [OE-core] [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Hi Saul,
Quoted 1 line · Saul Wold
Sorry for the top post here, looks like there might be some
difference
Quoted 1 line
during configuration and compilation, can you send your config.log
and
Quoted 4 lines
the log.do_configure along with log.do_compile to the list.
I think they need more investigation.
please find attached the two files.
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardAnd the config.log from the builddir is attached to this email.
Thanks,
Nitin
Quoted 36 lines
-----Original Message-----
From: Kamble, Nitin A
Sent: Wednesday, March 21, 2012 3:55 PM
To: 'Eric Bénard'; Saul Wold
Cc: Patches and discussions about the oe-core layer; Martin Jansa
Subject: RE: [OE-core] [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Eric, Saul,
Gdb-cross-canadian build logs from my build attached.
NitinQuoted 24 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 3:37 PM
To: Saul Wold
Cc: Patches and discussions about the oe-core layer; Kamble, Nitin A; Martin Jansa
Subject: Re: [OE-core] [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Hi Saul,
Quoted 1 line · Saul Wold
Sorry for the top post here, looks like there might be some
difference
Quoted 1 line
during configuration and compilation, can you send your config.log
and
Quoted 4 lines
the log.do_configure along with log.do_compile to the list.
I think they need more investigation.
please find attached the two files.
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Saul WoldHi,
thanks to the help of Woglinde on IRC, here is some log which shows a wrong rpath which explains why the sdk libraries are not used. This doesn't solves the double free problem which seems related to the SDK's libpython
Eric
$ chrpath -l arm-oe-linux-gnueabi-gdb arm-oe-linux-gnueabi-gdb: RPATH=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/armv5te-oe-linux-gnueabi:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib
$ ldd arm-oe-linux-gnueabi-gdb ./arm-oe-linux-gnueabi-gdb: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by /lib64/libz.so.1) linux-vdso.so.1 => (0x00007fff26fff000) libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ba3a00000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007f670a379000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007f670a156000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007f6709f2f000) libz.so.1 => /lib64/libz.so.1 (0x0000003ba3200000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007f6709cac000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007f6709a8f000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007f670988b000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003ba7200000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007f6709504000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003ba1600000)
$ find /usr/local/oecore-x86_64/ -iname libz* /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libz.so.1.2.6 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libz.so.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/var/lib/opkg/info/libz1.control /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/var/lib/opkg/info/libz1.list $ find /usr/local/oecore-x86_64/ -iname libreadline* /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libreadline.so.6.2 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libreadline.so.6 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/var/lib/opkg/info/libreadline6.control /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/var/lib/opkg/info/libreadline6.list $ find /usr/local/oecore-x86_64/ -iname libexpat* /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libexpat.so.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libexpat.so.1.5.2 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/var/lib/opkg/info/libexpat1.control /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/var/lib/opkg/info/libexpat1.list
$ sudo chrpath -r "/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib" arm-oe-linux-gnueabi-gdb arm-oe-linux-gnueabi-gdb: RPATH=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/armv5te-oe-linux-gnueabi:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib arm-oe-linux-gnueabi-gdb: new RPATH: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib $ ldd arm-oe-linux-gnueabi-gdb linux-vdso.so.1 => (0x00007fff215ff000) libreadline.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libreadline.so.6 (0x00007f1603aa2000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007f160389d000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007f160367a000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007f1603453000) libz.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libz.so.1 (0x00007f160323d000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007f1602fbb000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007f1602d9e000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007f1602b9a000) libexpat.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libexpat.so.1 (0x00007f1602971000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007f16025ea000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003ba1600000)
$ arm-oe-linux-gnueabi-gdb *** glibc detected *** arm-oe-linux-gnueabi-gdb: double free or corruption (out): 0x0000000002347030 *** Abandon (core dumped)
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardQuoted 3 lines
Looks like in my case the sdk gdb is not dynamically linked with libpython.
And also sdk provides libpython.so so gdb should be linked with the sdk version and not the host-distro version.
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardQuoted 5 lines · Eric Bénard
Quoted 2 lines · Nitin A
If it is working for you, I don't understand why is it not working here.
it's not working _only_ for me, Martin also had success.
Tested again this time with SDKMACHINE ?= "x86-64"
and notice that for me it uses libz libpython2.7 from sdk.
OE @ /usr/local/oecore-x86_64 $ x86_64-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-oesdk-linux --target=x86_64-oe-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) python print 42
42
(gdb) quit
OE @ /usr/local/oecore-x86_64 $ which x86_64-oe-linux-gdb /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
OE @ /usr/local/oecore-x86_64 $ ldd /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
linux-vdso.so.1 (0x00007ffffdfff000)
libreadline.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libreadline.so.6 (0x00007fd92e32e000)
libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007fd92e12a000)
libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007fd92df07000)
libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007fd92dce0000)
libz.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libz.so.1 (0x00007fd92dacb000)
libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007fd92d7d7000)
libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007fd92d5ba000)
libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007fd92d3b7000)
libpython2.7.so.1.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libpython2.7.so.1.0 (0x00007fd92cfe8000)
libexpat.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libexpat.so.1 (0x00007fd92cdbf000)
libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007fd92ca1a000)
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 (0x00007fd92e56e000)Quoted 84 lines
Quoted 23 lines
[nitin@nbuild0 oecore-x86_64]$ cd
/usr/local/oecore-x86_64/
[nitin@nbuild0 oecore-x86_64]$ ls
environment-setup-x86_64-oe-linux site-config-x86_64-oe-linux sysroots version-x86_64-oe-linux
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux
[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-gdblinux-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)Quoted 2 lines
I am seeing that the sdk gdb is dynamically linking with some of the host libraries as seen above.
ebenard@eb-e6520 x86_64-oe-linux]$ ldd x86_64-oe-linux-gdb
./x86_64-oe-linux-gdb:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: versionGLIBC_2.14' not found (required by /lib64/libz.so.1) ./x86_64-oe-linux-gdb: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: versionGLIBC_2.14' not found (required by/usr/lib64/libpython2.7.so.1.0)linux-vdso.so.1 => (0x00007fff12dff000) libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ba3a00000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007fbfa6c67000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007fbfa6a44000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007fbfa681d000) libz.so.1 => /lib64/libz.so.1 (0x0000003ba3200000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007fbfa659a000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007fbfa637d000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007fbfa6179000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003bb3000000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003ba7200000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007fbfa5df1000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003ba1600000)[ebenard@eb-e6520 x86_64-oe-linux]$ ./x86_64-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-oesdk-linux --target=x86_64-oe-linux". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
[ebenard@eb-e6520 x86_64-oe-linux]$ cd ../i586-oe-linux/[ebenard@eb-e6520 i586-oe-linux]$ ldd i586-oe-linux-gdb
./i586-oe-linux-gdb:/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: versionGLIBC_2.14' not found (required by /lib64/libz.so.1) ./i586-oe-linux-gdb: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: versionGLIBC_2.14' not found (required by/usr/lib64/libpython2.7.so.1.0)linux-vdso.so.1 => (0x00007fff7c949000) libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ba3a00000) libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007fe6f9c74000) libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007fe6f9a51000) libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007fe6f982a000) libz.so.1 => /lib64/libz.so.1 (0x0000003ba3200000) libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007fe6f95a7000) libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007fe6f938a000) libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007fe6f9186000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x0000003bb3000000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003ba7200000) libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007fe6f8dfe000) /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003ba1600000)[ebenard@eb-e6520 i586-oe-linux]$ ./i586-oe-linux-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-oesdk-linux --target=i586-oe-linux". For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) quitSignature · 1 line
http://eukrea.com/en/news/104-2012
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 11 lines · Martin Jansa
Quoted 5 lines · Eric Bénard
Quoted 2 lines · Nitin A
If it is working for you, I don't understand why is it not working here.
it's not working _only_ for me, Martin also had success.
Tested again this time with SDKMACHINE ?= "x86-64"
and notice that for me it uses libz libpython2.7 from sdk.
I cleaned my tmp, removed the installed SDK and now I reproduce Nitin's problem. So there is something strange here.
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Kamble, Nitin AQuoted 7 lines · Nitin A
Quoted 7 lines
Hi Nitin,
FWIW I took the i586 target sdk generated on the Fedora 16 and put it on a VirtualBox VM running ubuntu 10.04.3 LTS
x86_64(2.6.32 kernel) and gdb still works fine.
Quoted 8 lines
Quoted 1 line
Eric
Eric,
If it is working for you, I don't understand why is it not working here.[nitin@nbuild0 oecore-x86_64]$ cd
/usr/local/oecore-x86_64/[nitin@nbuild0 oecore-x86_64]$ ls environment-setup-x86_64-oe-linux site-config-x86_64-oe-linux sysroots
version-x86_64-oe-linux
Quoted 2 lines
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux [nitin@nbuild0 oecore-x86_64]$
./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
Quoted 1 line
*** glibc detected ***
./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb:
double free or corruption (out): 0x00007f3226818030 ***
Quoted 2 lines
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
Quoted 3 lines
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)
Quoted 1 line
libncurses.so.5 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007fa20784f000)
Quoted 1 line
libtinfo.so.5 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007fa207628000)
Quoted 2 lines
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)
Quoted 1 line
libpthread.so.0 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007fa207188000)
Quoted 1 line
libutil.so.1 =>
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007fa206f84000)
Quoted 2 lines
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)
Quoted 1 line
/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)
Quoted 3 lines
I am seeing that the sdk gdb is dynamically linking with some of the host
libraries as seen above.
Quoted 1 line
I think host libs is issue here
Why is libexpat libreadline libz being used from build host
Quoted 8 lines
Nitin
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 18 lines
[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-gdblinux-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)
Quoted 2 lines
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
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 9 lines · Nitin A
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.
OK can you generate the gdb core and post it. I can debug whats causing it.
Quoted 1 line
Thanks,
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 19 lines
-----Original Message-----
From: Khem Raj [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 9:25 PM
To: Kamble, Nitin A
Cc: Patches and discussions about the oe-core layer; Martin Jansa; Eric Bénard
Subject: Re: [OE-core] [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 1 line · Nitin A
Actually we noticed that Eric’s working sdk gdb was getting linked
with the
Quoted 1 line
host libpython.so, And if it is linked with the sdk libpython.so then
he is
Quoted 2 lines
able to see same issue what I am seeing.
Quoted 9 lines
Quoted 5 lines
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.
OK can you generate the gdb core and post it. I can debug whats causing it.
Khem,
Thanks for helping out. I also have uploaded the core file here: http://min.us/mbii28QmkZ
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 14 lines · Nitin A
Quoted 14 lines
Quoted 1 line · Nitin A
Actually we noticed that Eric’s working sdk gdb was getting linked
with the
Quoted 1 line
host libpython.so, And if it is linked with the sdk libpython.so then
he is
Quoted 7 lines
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.
Quoted 6 lines
Quoted 3 lines
OK can you generate the gdb core and post it. I can debug whats causing it.
Khem,
Thanks for helping out. I also have uploaded the core file here: http://min.us/mbii28QmkZ
ok also try setting MALLOC_CHECK_=2 in environment and run gdb again this should dump the core
I dont have gdb handy right now its building
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 20 lines · Khem Raj
Quoted 18 lines · Nitin A
Quoted 17 lines
Quoted 1 line · Nitin A
Actually we noticed that Eric’s working sdk gdb was getting linked
with the
Quoted 1 line
host libpython.so, And if it is linked with the sdk libpython.so then
he is
Quoted 7 lines
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.
OK can you generate the gdb core and post it. I can debug whats causing it.
Quoted 6 lines
Quoted 2 lines
Khem,
Thanks for helping out. I also have uploaded the core file here: http://min.us/mbii28QmkZok also try setting MALLOC_CHECK_=2 in environment and run gdb again this should dump the core
I dont have gdb handy right now its building
just for test try to move sysroots/x86_64-pokysdk-linux/usr/lib/python2.7/lib-dynload/readline.so out of way and retry see if this works ?
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Khem RajHi Khem,
Quoted 3 lines · Khem Raj
ok also try setting MALLOC_CHECK_=2 in environment and run gdb again this should dump the core
I dont have gdb handy right now its building
$ export MALLOC_CHECK_=2 $ ./arm-oe-linux-gnueabi-gdb Abandon (core dumped) $ sudo rm ../../lib/libreadline.so.6* $ ./arm-oe-linux-gnueabi-gdb Abandon (core dumped) $ sudo rm ../../lib/libpython2.7.so.1.0 $ ./arm-oe-linux-gnueabi-gdb GNU gdb (GDB) 7.4 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-oesdk-linux --target=arm-oe-linux-gnueabi". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. (gdb)
so the problem seems to be in the libpython of the SDK
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 2 lines · Eric Bénard
so the problem seems to be in the libpython of the SDK
delete the readline.so in python modules and use the SDK python does that make the crash go away ?
libpython sometimes expect debug versions of plugins and thats what I am getting to
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Hi Khem,
Quoted 8 lines · Khem Raj
Quoted 2 lines · Eric Bénard
so the problem seems to be in the libpython of the SDK
delete the readline.so in python modules and use the SDK python does that make the crash go away ?
libpython sometimes expect debug versions of plugins and thats what I am getting to
you are right :
$ sudo rm ../../lib/python2.7/lib-dynload/readline.so $ ./arm-oe-linux-gnueabi-gdb GNU gdb (GDB) 7.4 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-oesdk-linux --target=arm-oe-linux-gnueabi". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. (gdb)
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 3 lines · Eric Bénard
you are right :
$ sudo rm ../../lib/python2.7/lib-dynload/readline.so
ok another experiment instead of deleting readline.so make a copy of it and call it
readline_d.so in the same dir or whereever gdb looks for debug symbols and see if it still works or do you get the segfault again.
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 9 lines · Khem Raj
Quoted 3 lines · Eric Bénard
you are right :
$ sudo rm ../../lib/python2.7/lib-dynload/readline.sook another experiment instead of deleting readline.so make a copy of it and call it
readline_d.so in the same dir or whereever gdb looks for debug symbols and see if it still works or do you get the segfault again.
true :
[ebenard@eb-e6520 lib-dynload]$ sudo mv readline.so readline_d.so [ebenard@eb-e6520 lib-dynload]$ arm-oe-linux-gnueabi-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-oesdk-linux --target=arm-oe-linux-gnueabi". For bug reporting instructions, please
see: <http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 4 lines · Eric Bénard
[ebenard@eb-e6520 lib-dynload]$ sudo mv readline.so readline_d.so [ebenard@eb-e6520 lib-dynload]$ arm-oe-linux-gnueabi-gdb GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
Quoted 9 lines
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-oesdk-linux --target=arm-oe-linux-gnueabi". For bug reporting instructions, please
see: <http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
please note that cp readline.so readline_d.so didn't work, I had to do mv readline.so readline_d.so
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 16 lines · Eric Bénard
Quoted 4 lines · Eric Bénard
[ebenard@eb-e6520 lib-dynload]$ sudo mv readline.so readline_d.so [ebenard@eb-e6520 lib-dynload]$ arm-oe-linux-gnueabi-gdb GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.Quoted 9 lines
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-oesdk-linux --target=arm-oe-linux-gnueabi". For bug reporting instructions, please
see: <http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
Quoted 2 lines
please note that cp readline.so readline_d.so didn't work, I had to do mv readline.so readline_d.so
yeah mv is ok in this case since it should be otherwise in the usr/debug dir OK so I think the problem is this we are not generating *_d.so files in python-native.
when using python in gdb debug interpreter expects the _d.so files
Quoted 3 lines
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardQuoted 40 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Thursday, March 22, 2012 6:15 AM
To: Khem Raj
Cc: Kamble, Nitin A; Patches and discussions about the oe-core layer; Martin Jansa
Subject: Re: [OE-core] [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 8 lines · Khem Raj
Quoted 3 lines · Eric Bénard
you are right :
$ sudo rm ../../lib/python2.7/lib-dynload/readline.sook another experiment instead of deleting readline.so make a copy of it and call it
readline_d.so in the same dir or whereever gdb looks for debugsymbols
Quoted 1 line
and see if it still works or do you get the segfault again.
true :
[ebenard@eb-e6520 lib-dynload]$ sudo mv readline.so readline_d.so [ebenard@eb-e6520 lib-dynload]$ arm-oe-linux-gnueabi-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-oesdk-linux --target=arm-oe-linux-gnueabi". For bug reporting instructions, please
see: <http://www.gnu.org/software/gdb/bugs/>.
(gdb) quit
Quoted 1 line
Eric
Khem, Eric,
Renaming the sdk python2.7/lib-dynload/readline.so to python2.7/lib-dynload/readline_d.so gets the sdk gdb working for me too. So is this a workaround or solution to the problem? If it is a workaround what should be right solution?
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 3 lines · Nitin A
Renaming the sdk python2.7/lib-dynload/readline.so to python2.7/lib-dynload/readline_d.so gets the sdk gdb working for me too. So is this a workaround or solution to the problem? If it is a workaround what should be right solution?
I think we should be generating these _d.so files during python-native build. So please look into why its not happening. I wont have much chance during the day to look at that
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 15 lines
-----Original Message-----
From: Khem Raj [mailto:[email protected]]
Sent: Thursday, March 22, 2012 9:38 AM
To: Kamble, Nitin A
Cc: Eric Bénard; Patches and discussions about the oe-core layer; Martin Jansa
Subject: Re: [OE-core] [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 2 lines · Nitin A
Renaming the sdk python2.7/lib-dynload/readline.so to python2.7/lib-
Quoted 8 lines
dynload/readline_d.so gets the sdk gdb working for me too.
Quoted 1 line
So is this a workaround or solution to the problem? If it is a
workaround what should be right solution?
I think we should be generating these _d.so files during python-native build. So please look into why its not happening. I wont have much chance
during the day to look at that
Looks like we need this patch for the python recipe to generate debug modules:
http://patch-tracker.debian.org/patch/series/view/python2.7/2.7.2-8/debug-build.diff
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 8 lines · Nitin A
Quoted 8 lines
Quoted 2 lines · Nitin A
Renaming the sdk python2.7/lib-dynload/readline.so to python2.7/lib-
dynload/readline_d.so gets the sdk gdb working for me too.
Quoted 1 line
So is this a workaround or solution to the problem? If it is a
workaround what should be right solution?
Quoted 7 lines
Quoted 4 lines
I think we should be generating these _d.so files during python-native build. So please look into why its not happening. I wont have much chance
during the day to look at thatLooks like we need this patch for the python recipe to generate debug modules:
http://patch-tracker.debian.org/patch/series/view/python2.7/2.7.2-8/debug-build.diff
yep thats the one. Apply it to python and rebuild python-native and stage it then see if that helps. You might have to adjust the FILES and PACKAGES to put the new files in right places.
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Hi Khem, Hi Nitin,
Quoted 8 lines · Khem Raj
Quoted 2 lines · Nitin A
Looks like we need this patch for the python recipe to generate debug modules:
http://patch-tracker.debian.org/patch/series/view/python2.7/2.7.2-8/debug-build.diffyep thats the one. Apply it to python and rebuild python-native and stage it then see if that helps. You might have to adjust the FILES and PACKAGES to put the new files in right places.
With this patch all the libraries (including libpython2.7) now have a _d suffix : is that what we really want ?
Once that's hacked in the recipe so that do_compile works - in case
someone has an idea - I get a failure during installation of
python-nativesdk :build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/python-nativesdk-2.7.2-r1.9/image/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/sysconfig.py :
return os.path.join(get_path('platstdlib'), "config" + (sys.pydebug and
"_d" or ""), "Makefile") | AttributeError: 'module' object has no
attribute 'pydebug
I checked on both debian & fedora and they are using this patch only to generate debug packages, not for the standard package. Moreover, when I execute gdb on my PC (Fedora 16) it runs fine and I don't have readline_d.so installed in lib-dynload so it seems possible to get gdb to work with python without having debug symbols.
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 40 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Thursday, March 22, 2012 2:31 PM
To: Khem Raj
Cc: Kamble, Nitin A; Patches and discussions about the oe-core layer; Martin Jansa
Subject: Re: [OE-core] [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Hi Khem, Hi Nitin,
Quoted 3 lines · Khem Raj
Quoted 1 line · Nitin A
Looks like we need this patch for the python recipe to generate
debug modules:
Quoted 1 line
8/debug-build.diffQuoted 4 lines
yep thats the one. Apply it to python and rebuild python-native and stage it then see if that helps. You might have to adjust the FILES and PACKAGES to put the new files in right places.
With this patch all the libraries (including libpython2.7) now have a _d
suffix : is that what we really want ?Once that's hacked in the recipe so that
do_compileworks - in case someone has an idea - I get a failure during installation of python-nativesdk :
build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/python-nativesdk- 2.7.2-r1.9/image/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/sysconfig.py:
returnos.path.join(get_path('platstdlib'), "config" + (sys.pydebug and "_d" or ""), "Makefile")| AttributeError: 'module' object has no attribute 'pydebug
Quoted 7 lines
I checked on both debian & fedora and they are using this patch only to generate debug packages, not for the standard package. Moreover, when I execute gdb on my PC (Fedora 16) it runs fine and I don't have readline_d.so installed in lib-dynload so it seems possible to get gdb to work with python without having debug symbols.
Eric
Hi Eric, Khem,
I am also having very similar thoughts here. My fedora does not have
readline_d.so installed, and that is not a problem for host gdb.
The install issue you are seeing is due to python-native which is used in the nativesdk install process, it is expecting "pydebug" enabled in the native version also. And I could not get that patch applied to the python-native successfully (another build issue).
Anyways, we 1st need to understand, how gdb in mainline distros like fedora is able to work fine without having the debug python modules installed.
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Hi,
Quoted 8 lines · Nitin A
I am also having very similar thoughts here. My fedora does not have
readline_d.so installed, and that is not a problem for host gdb.The install issue you are seeing is due to python-native which is used in the nativesdk install process, it is expecting "pydebug" enabled in the native version also. And I could not get that patch applied to the python-native successfully (another build issue).
same thing here, I also tried that ;-)
Quoted 3 lines
Anyways, we 1st need to understand, how gdb in mainline distros like fedora is able to work fine without having the debug python modules installed.
yes I think that's also the right way to solve the problem instead of using the workaround found.
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardKhem,
Can you help me understand why renaming readline.so to readline_d.so
is solving the core dump (or double free) issue?
As noted in another email, the host gdb on fedora is able working fine
without need of readline_d.so; so providing readline_d.so is also seems to be a workaround over a real issue.
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 6 lines · Nitin A
Can you help me understand why renaming readline.so to readline_d.so
is solving the core dump (or double free) issue?As noted in another email, the host gdb on fedora is able working fine
without need of readline_d.so; so providing readline_d.so is also seems to be a workaround over a real issue.
I havent been able to reproduce it on my end exactly here. The problem seems to be that the readline.so library is being released twice (somehow) it could be that fedora python carries a patch that solves this issue. I havent looked. Once I am able to repduce the crash then I can comment more.
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardQuoted 24 lines · Eric Bénard
Hi Khem, Hi Nitin,
Quoted 8 lines · Khem Raj
Quoted 2 lines · Nitin A
Looks like we need this patch for the python recipe to generate debug modules:
http://patch-tracker.debian.org/patch/series/view/python2.7/2.7.2-8/debug-build.diffyep thats the one. Apply it to python and rebuild python-native and stage it then see if that helps. You might have to adjust the FILES and PACKAGES to put the new files in right places.
With this patch all the libraries (including libpython2.7) now have a _d suffix : is that what we really want ?
Once that's hacked in the recipe so that
do_compileworks - in case
someone has an idea - I get a failure during installation of
python-nativesdk :build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/python-nativesdk-2.7.2-r1.9/image/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/sysconfig.py:
return os.path.join(get_path('platstdlib'), "config" + (sys.pydebug and
"_d" or ""), "Makefile") | AttributeError: 'module' object has no
attribute 'pydebug
Quoted 7 lines
I checked on both debian& fedora and they are using this patch only to generate debug packages, not for the standard package. Moreover, when I execute gdb on my PC (Fedora 16) it runs fine and I don't have readline_d.so installed in lib-dynload so it seems possible to get gdb to work with python without having debug symbols.
Eric
when I launch gdb I end up with
Traceback (most recent call last):
File "/usr/lib/python2.7/site.py", line 562, in <module>
main()
File "/usr/lib/python2.7/site.py", line 544, in main
known_paths = addusersitepackages(known_paths)
File "/usr/lib/python2.7/site.py", line 271, in addusersitepackages
user_site = getusersitepackages()
File "/usr/lib/python2.7/site.py", line 246, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
File "/usr/lib/python2.7/site.py", line 236, in getuserbase
USER_BASE = get_config_var('userbase')
File "/usr/lib/python2.7/sysconfig.py", line 543, in get_config_var
return get_config_vars().get(name)
File "/usr/lib/python2.7/sysconfig.py", line 442, in get_config_vars
_init_posix(_CONFIG_VARS)
File "/usr/lib/python2.7/sysconfig.py", line 303, in _init_posix
makefile = _get_makefile_filename()
File "/usr/lib/python2.7/sysconfig.py", line 297, in_get_makefile_filename
return
os.path.join(get_path('platstdlib').replace("/usr/local","/usr",1), "config" + (sys.pydebug and "_d" or ""), "Makefile")
AttributeError: 'module' object has no attribute 'pydebug'
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardQuoted 24 lines · Eric Bénard
Hi Khem, Hi Nitin,
Quoted 8 lines · Khem Raj
Quoted 2 lines · Nitin A
Looks like we need this patch for the python recipe to generate debug modules:
http://patch-tracker.debian.org/patch/series/view/python2.7/2.7.2-8/debug-build.diffyep thats the one. Apply it to python and rebuild python-native and stage it then see if that helps. You might have to adjust the FILES and PACKAGES to put the new files in right places.
With this patch all the libraries (including libpython2.7) now have a _d suffix : is that what we really want ?
Once that's hacked in the recipe so that
do_compileworks - in case
someone has an idea - I get a failure during installation of
python-nativesdk :build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/python-nativesdk-2.7.2-r1.9/image/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/sysconfig.py:
return os.path.join(get_path('platstdlib'), "config" + (sys.pydebug and
"_d" or ""), "Makefile") | AttributeError: 'module' object has no
attribute 'pydebug
Quoted 7 lines
I checked on both debian& fedora and they are using this patch only to generate debug packages, not for the standard package. Moreover, when I execute gdb on my PC (Fedora 16) it runs fine and I don't have readline_d.so installed in lib-dynload so it seems possible to get gdb to work with python without having debug symbols.
Eric
OK can you try following patch ? (untested) it does not fix the paths so once you install sdk it will have to be fixed as you did with chrpath for testing
http://paste.ubuntu.com/896082/
I think issue is currently we are linking with static version of libpython and also the search path to find python executable for gdb when running is /usr/bin and not the python from SDK so this patch takes care of both
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Hi Khem,
Quoted 11 lines · Khem Raj
OK can you try following patch ? (untested) it does not fix the paths so once you install sdk it will have to be fixed as you did with chrpath for testing
http://paste.ubuntu.com/896082/
I think issue is currently we are linking with static version of libpython and also the search path to find python executable for gdb when running is
/usr/binand not the python from SDK so this patch takes care of both
very good catch, now gdb runs fine and strace shows that it loads the right library :
open("/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/lib-dynload/readline.so", O_RDONLY) = 6 fstat(6, {st_mode=S_IFREG|0755, st_size=23520, ...}) = 0 futex(0x7f3ada48e0a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/lib-dynload/readline.so", O_RDONLY) = 7 read(7, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`%\0\0\0\0\0\0"..., 832)
= 832 fstat(7, {st_mode=S_IFREG|0755, st_size=23520, ...}) = 0
mmap(NULL, 2118952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 7,
0) = 0x7f3ad8a05000
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 28 lines · Eric Bénard
Hi Khem,
Quoted 11 lines · Khem Raj
OK can you try following patch ? (untested) it does not fix the paths so once you install sdk it will have to be fixed as you did with chrpath for testing
http://paste.ubuntu.com/896082/
I think issue is currently we are linking with static version of libpython and also the search path to find python executable for gdb when running is
/usr/binand not the python from SDK so this patch takes care of bothvery good catch, now gdb runs fine and strace shows that it loads the right library :
open("/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/lib-dynload/readline.so",
O_RDONLY) = 6fstat(6, {st_mode=S_IFREG|0755, st_size=23520, ...})= 0futex(0x7f3ada48e0a8, FUTEX_WAKE_PRIVATE, 2147483647)= 0 open("/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/lib-dynload/readline.so",O_RDONLY) = 7 read(7, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`%\0\0\0\0\0\0"..., 832)
= 832fstat(7, {st_mode=S_IFREG|0755, st_size=23520, ...})= 0
mmap(NULL, 2118952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 7,
0) =0x7f3ad8a05000
Quoted 1 line
Eric
good. So this patch does the trick. I will post proper patch shortly we still need to fix the rpath problem though
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 42 lines
-----Original Message-----
From: Khem Raj [mailto:[email protected]]
Sent: Friday, March 23, 2012 5:07 AM
To: Eric Bénard
Cc: Kamble, Nitin A; Patches and discussions about the oe-core layer; Martin Jansa
Subject: Re: [OE-core] [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 5 lines · Eric Bénard
Hi Khem,
Quoted 1 line · Khem Raj
OK can you try following patch ? (untested) it does not fix the
paths so
Quoted 1 line
Quoted 1 line
once you install sdk it will have to be fixed as you did with
chrpath
Quoted 9 lines
Quoted 9 lines
for testing
http://paste.ubuntu.com/896082/
I think issue is currently we are linking with static version of libpython and also the search path to find python executable for gdb when running is
/usr/binand not the python from SDK so this patch takes care of bothQuoted 4 lines
very good catch, now gdb runs fine and strace shows that it loads the right library :
open("/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-
linux/usr/lib/python2.7/lib-dynload/readline.so",
Quoted 1 line
O_RDONLY) = 6fstat(6, {st_mode=S_IFREG|0755, st_size=23520, ...})=0
Quoted 2 lines
futex(0x7f3ada48e0a8, FUTEX_WAKE_PRIVATE, 2147483647)= 0 open("/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/lib-dynload/readline.so",
Quoted 2 lines
O_RDONLY) = 7 read(7, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`%\0\0\0\0\0\0"...,832)
Quoted 2 lines
= 832
fstat(7, {st_mode=S_IFREG|0755, st_size=23520, ...})= 0 mmap(NULL, 2118952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
Quoted 7 lines
7,
Quoted 3 lines
0) =
0x7f3ad8a05000Eric
good. So this patch does the trick. I will post proper patch shortly we still need to fix the rpath problem though
Khem,
Thanks for fixing the gdb issue at the root cause. And I have a fix for the rpath issue.
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardAlso executing sdk gdb on the same build system (suse) is giving the same error.
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 2 lines · Nitin A
Also executing sdk gdb on the same build system (suse) is giving the same error.
do you have the possibility to launch a build on an other build system ?
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 8 lines
Quoted 2 lines
Also executing sdk gdb on the same build system (suse) is giving the
same error.
Quoted 1 line
do you have the possibility to launch a build on an other build system ?
Eric
Building on Fedora 15 (64bit) has given me same results. I am starting a build on fedora 16 (64 bit).
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardSorry to interject into the middle of this but I have a sudden idea. I suspect Nitin is using rpm and the people with successful builds are using ipk.
Further, I suspect that rpm is including python-nativesdk whilst the ipk version might not be due to its slightly better dependency detection.
So this could be something wrong with the python-nativesdk.
I'd be interested to see if this fails for Martin/Eric if they manually include python-nativesdk. Nitin, you could also try an ipk build.
Cheers,
Richard
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardQuoted 81 lines
-----Original Message-----
From: Kamble, Nitin A
Sent: Wednesday, March 21, 2012 2:12 PM
To: 'Eric Bénard'
Cc: Martin Jansa; [email protected]; [email protected]
Subject: RE: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 9 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 2:03 PM
To: Kamble, Nitin A
Cc: Martin Jansa; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 3 lines
Quoted 1 line · Nitin A
I removed the meta-yocto layer, which removed poky distro from
the
Quoted 10 lines
config. And I am still seeing same issue.
Quoted 4 lines
[nitin@nbuild0 /]$ cd
/usr/local/oecore-x86_64/[nitin@nbuild0 oecore-x86_64]$ ls environment-setup-x86_64-oe-linux site-config-x86_64-oe-linuxsysroots version-x86_64-oe-linux
Quoted 2 lines
[nitin@nbuild0 oecore-x86_64]$ . environment-setup-x86_64-oe-linux
[nitin@nbuild0 oecore-x86_64]$ sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
Quoted 1 line
*** glibc detected *** sysroots/x86_64-oesdk-linux/usr/bin/x86_64-
oe-
Quoted 6 lines
linux/x86_64-oe-linux-gdb: double free or corruption (out):
0x00007f3221852030***Quoted 2 lines
Aborted (core dumped)
may you please provide details on :
- log reported by bitbake when you launch it to know a little bitmore
Quoted 1 line
your configuration,
This is with yocto git repo, with just meta layer, I removed the meta- yocto layer from configuration to keep just oecore bits and to take out the poky bits.
$ bitbake meta-toolchain Pseudo is not present but is required, building this first before the main build Parsing recipes: 100% |###################################################################### #######| Time: 00:00:03 Parsing of 831 .bb files complete (0 cached, 831 parsed). 1107 targets, 19 skipped, 0 masked, 0 errors.OE Build Configuration:
BB_VERSION = "1.15.1" TARGET_ARCH = "x86_64" TARGET_OS = "linux" MACHINE = "qemux86-64" DISTRO = "" DISTRO_VERSION = "oe-core.0" TUNE_FEATURES = "m64" TARGET_FPU = "" meta = "master:40f95685e6a3b4359d2ab2fea1418fe5e4bd0aa1"Quoted 1 line
- host distribution and arch of your build host
Build host:
$ cat /etc/SuSE-release openSUSE 11.4 (x86_64) VERSION = 11.4 CODENAME = Celadon $ uname -a Linux yocto-hm1 2.6.37.6-0.7-default #1 SMP 2011-07-21 02:17:24 +0200 x86_64 x86_64 x86_64 GNU/LinuxSDK machine host:
Quoted 8 lines
$ cat /etc/redhat-release Fedora release 15 (Lovelock) $ uname -a Linux nbuild0.sc.intel.com 2.6.40.6-0.fc15.x86_64 #1 SMP Tue Oct 4 00:39:50 UTC 2011 x86_64 x86_64 x86_64 GNU/LinuxNext I am also trying to build from the oe-core git tree.
And the sources from oecore repository http://cgit.openembedded.org/openembedded-core/log/
are resulting in the same gdb issue.
$ bitbake meta-toolchain Pseudo is not present but is required, building this first before the main build Parsing recipes: 100% |#############################################################################| Time: 00:00:03 Parsing of 831 .bb files complete (0 cached, 831 parsed). 1107 targets, 19 skipped, 0 masked, 0 errors.
OE Build Configuration:
BB_VERSION = "1.15.1" TARGET_ARCH = "x86_64" TARGET_OS = "linux" MACHINE = "qemux86-64" DISTRO = "" DISTRO_VERSION = "oe-core.0" TUNE_FEATURES = "m64" TARGET_FPU = "" meta = "master:b60d0c57a2e16d690fd11c6349917efc57630004"
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardQuoted 24 lines
Quoted 12 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 11:02 AM
To: Kamble, Nitin A
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Quoted 4 lines
Quoted 2 lines · Nitin A
Can you try meta-toolchain for qemux86 or qemux86-64 machine ? I found that sdk gdb is failing for these machines since that
commit
Quoted 3 lines
went in the oe-core.
Quoted 1 line
I'm launching a build and will keep you informed of the result. If
that
Quoted 3 lines
only fails for x86 or
x86_64targets, we can use overrides to disable python support only for these targets.
Quoted 8 lines
Quoted 1 line
Eric
I also starting test for sdk gdb for qemuarm target. Will keep you posted. Any solution that gives a working sdk gdb for all arches will be good.
Thanks,
Nitin
Eric,
The sdk gdb from meta-toolchain for qemuarm is also failing similarly:
*** glibc detected *** arm-poky-linux-gnueabi-gdb: double free or corruption (out): 0x00007f8ef7992030 *** Aborted (core dumped)
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Hi Nitin,
Quoted 5 lines · Nitin A
The sdk gdb from meta-toolchain for qemuarm is also failing similarly:
*** glibc detected *** arm-poky-linux-gnueabi-gdb: double free or corruption (out):
0x00007f8ef7992030*** Aborted (core dumped)
can you provide more details on your configuration as it seems you have a problem somewhere else ?
here is my config (you already have host details in the previous email) [ebenard@eb-e6520 build]$ bitbake-layers show-layers Parsing recipes..done.
layer path priority
==========================================================================
meta /home/ebenard/OE-CORE/openembedded-core/meta
OE Build Configuration:
BB_VERSION = "1.15.1" TARGET_ARCH = "i586" TARGET_OS = "linux" MACHINE = "qemux86" DISTRO = "" DISTRO_VERSION = "oe-core.0" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta = "master:ee00c3146525e481beaefd2149c61cfe51de2797"
Eric
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
Quoted 46 lines
-----Original Message-----
From: Eric Bénard [mailto:[email protected]]
Sent: Wednesday, March 21, 2012 12:37 PM
To: Kamble, Nitin A
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"Hi Nitin,
Quoted 1 line · Nitin A
The sdk gdb from meta-toolchain for qemuarm is also failing
similarly:
Quoted 2 lines
*** glibc detected *** arm-poky-linux-gnueabi-gdb: double free or
corruption (out):
0x00007f8ef7992030***Quoted 2 lines
Aborted (core dumped)
can you provide more details on your configuration as it seems you have a problem somewhere else ?
here is my config (you already have host details in the previous email) [ebenard@eb-e6520 build]$ bitbake-layers show-layers Parsing recipes..done.
layer path
priority
=======================================================================
===
meta/home/ebenard/OE-CORE/openembedded-core/metaOE Build Configuration:
BB_VERSION = "1.15.1" TARGET_ARCH = "i586" TARGET_OS = "linux" MACHINE = "qemux86" DISTRO = "" DISTRO_VERSION = "oe-core.0" TUNE_FEATURES = "m32 i586" TARGET_FPU = "" meta = "master:ee00c3146525e481beaefd2149c61cfe51de2797"
Quoted 1 line
Eric
I am on the yocto/oe-core master branch: http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/
I can try reproducing this issue with http://cgit.openembedded.org/openembedded-core/log/ and see what happens.
Thanks,
Nitin
Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with python support"
In reply to Eric BénardQuoted 7 lines · Eric Bénard
Quoted 2 lines · Nitin A
I tried removing the "--with-system-readline" from the
EXTRA_OECONF. It did not change the behavior of the issue.
Also I noticed that that commit never worked in the tree. I have built it on fedora and suse systems.it works fine here (Fedora 16
x86_64host system, oe-core + qemuarm target + meta-toolchain-qte), tested yersterday.
Here too with armv4t/armv7a + meta-toolchain-gmae.
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]