[PATCH 0/1] fix for the sdk gdb issue

[PATCH 0/1] fix for the sdk gdb issue

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

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(-)

-- 
1.7.6.4

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

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

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

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 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(-)

diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
index a7cac61..ec0748e 100644
--- a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
+++ b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
@@ -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"
diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian_7.4.bb b/meta/recipes-devtools/gdb/gdb-cross-canadian_7.4.bb
index dbcffde..dfb7d81 100644
--- a/meta/recipes-devtools/gdb/gdb-cross-canadian_7.4.bb
+++ b/meta/recipes-devtools/gdb/gdb-cross-canadian_7.4.bb
@@ -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"
-- 
1.7.6.4

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

[Eric Bénard]

Hi Nitin,

Le Wed, 21 Mar 2012 09:35:16 -0700,
nitin.a.kamble@intel.com a écrit :

> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> 
> 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
-- 
http://eukrea.com/en/news/104-2012

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

[Kamble, Nitin A]

> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> Sent: Wednesday, March 21, 2012 10:08 AM
> To: Kamble, Nitin A
> Cc: openembedded-core@lists.openembedded.org; Martin.Jansa@gmail.com;
> richard.purdie@linuxfoundation.org
> Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> python support"
> 
> Hi Nitin,
> 
> Le Wed, 21 Mar 2012 09:35:16 -0700,
> nitin.a.kamble@intel.com a écrit :
> 
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > 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
> --
> 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"

[Eric Bénard]

Le Wed, 21 Mar 2012 17:47:53 +0000,
"Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
>   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"

[Kamble, Nitin A]

> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> Sent: Wednesday, March 21, 2012 10:52 AM
> To: Kamble, Nitin A
> Cc: openembedded-core@lists.openembedded.org; Martin.Jansa@gmail.com;
> richard.purdie@linuxfoundation.org
> Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> python support"
> 
> Le Wed, 21 Mar 2012 17:47:53 +0000,
> "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> >   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

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"

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

On Wed, Mar 21, 2012 at 06:52:16PM +0100, Eric Bénard wrote:
> Le Wed, 21 Mar 2012 17:47:53 +0000,
> "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> >   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.

Here too with armv4t/armv7a + meta-toolchain-gmae.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Eric Bénard]

Le Wed, 21 Mar 2012 17:57:57 +0000,
"Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> 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"

[Kamble, Nitin A]

> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> Sent: Wednesday, March 21, 2012 11:02 AM
> To: Kamble, Nitin A
> Cc: openembedded-core@lists.openembedded.org; Martin.Jansa@gmail.com;
> richard.purdie@linuxfoundation.org
> Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> python support"
> 
> Le Wed, 21 Mar 2012 17:57:57 +0000,
> "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> > 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

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"

[Kamble, Nitin A]

> 
> 
> 
> > -----Original Message-----
> > From: Eric Bénard [mailto:eric@eukrea.com]
> > Sent: Wednesday, March 21, 2012 11:02 AM
> > To: Kamble, Nitin A
> > Cc: openembedded-core@lists.openembedded.org; Martin.Jansa@gmail.com;
> > richard.purdie@linuxfoundation.org
> > Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> > python support"
> >
> > Le Wed, 21 Mar 2012 17:57:57 +0000,
> > "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> > > 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
> 
> 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"

[Eric Bénard]

Hi Nitin,

Le Wed, 21 Mar 2012 18:07:50 +0000,
"Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> > From: Eric Bénard [mailto:eric@eukrea.com]
> > 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
> 
> 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"

[Eric Bénard]

Hi Nitin,

Le Wed, 21 Mar 2012 19:04:14 +0000,
"Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
>   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"

[Kamble, Nitin A]

> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> Sent: Wednesday, March 21, 2012 12:37 PM
> To: Kamble, Nitin A
> Cc: openembedded-core@lists.openembedded.org; Martin.Jansa@gmail.com;
> richard.purdie@linuxfoundation.org
> Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> python support"
> 
> Hi Nitin,
> 
> Le Wed, 21 Mar 2012 19:04:14 +0000,
> "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> >   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

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"

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3392 bytes --]

On Wed, Mar 21, 2012 at 08:32:49PM +0100, Eric Bénard wrote:
> Hi Nitin,
> 
> Le Wed, 21 Mar 2012 18:07:50 +0000,
> "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> > > From: Eric Bénard [mailto:eric@eukrea.com]
> > > 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
> > 
> > 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) 

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,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Kamble, Nitin A]

> -----Original Message-----
> From: Martin Jansa [mailto:martin.jansa@gmail.com]
> Sent: Wednesday, March 21, 2012 12:49 PM
> To: Eric Bénard
> Cc: Kamble, Nitin A; openembedded-core@lists.openembedded.org;
> richard.purdie@linuxfoundation.org
> Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> python support"
> 
> On Wed, Mar 21, 2012 at 08:32:49PM +0100, Eric Bénard wrote:
> > Hi Nitin,
> >
> > Le Wed, 21 Mar 2012 18:07:50 +0000,
> > "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> > > > From: Eric Bénard [mailto:eric@eukrea.com] 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
> > >
> > > 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-
> l
> > 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 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)
> 
> 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,
> 
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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"

[Eric Bénard]

Le Wed, 21 Mar 2012 20:48:23 +0000,
"Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
>   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"

[Kamble, Nitin A]

> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> Sent: Wednesday, March 21, 2012 2:03 PM
> To: Kamble, Nitin A
> Cc: Martin Jansa; openembedded-core@lists.openembedded.org;
> richard.purdie@linuxfoundation.org
> Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> python support"
> 
> Le Wed, 21 Mar 2012 20:48:23 +0000,
> "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> >   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,

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"

> - 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

> 
> Thanks
> Eric

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

[Eric Bénard]

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"

[Kamble, Nitin A]

> -----Original Message-----
> From: Kamble, Nitin A
> Sent: Wednesday, March 21, 2012 2:12 PM
> To: 'Eric Bénard'
> Cc: Martin Jansa; openembedded-core@lists.openembedded.org;
> richard.purdie@linuxfoundation.org
> Subject: RE: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> python support"
> 
> 
> 
> > -----Original Message-----
> > From: Eric Bénard [mailto:eric@eukrea.com]
> > Sent: Wednesday, March 21, 2012 2:03 PM
> > To: Kamble, Nitin A
> > Cc: Martin Jansa; openembedded-core@lists.openembedded.org;
> > richard.purdie@linuxfoundation.org
> > Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> > python support"
> >
> > Le Wed, 21 Mar 2012 20:48:23 +0000,
> > "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> > >   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,
> 
> 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"
> 
> > - 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.

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"

[Kamble, Nitin A]

> 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"

[Kamble, Nitin A]

Also 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"

[Eric Bénard]

Le Wed, 21 Mar 2012 21:53:10 +0000,
"Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
>  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.

> [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.
> 
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

-- 
http://eukrea.com/en/news/104-2012

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

[Eric Bénard]

Le Wed, 21 Mar 2012 22:04:42 +0000,
"Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :

> 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"

[Kamble, Nitin A]

> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> Sent: Wednesday, March 21, 2012 3:05 PM
> To: Kamble, Nitin A
> Cc: Martin Jansa; openembedded-core@lists.openembedded.org;
> richard.purdie@linuxfoundation.org
> Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
> python support"
> 
> Le Wed, 21 Mar 2012 21:53:10 +0000,
> "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> >  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.
> 
> > [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.
> >
> 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
> 
> --
> http://eukrea.com/en/news/104-2012


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"

[Saul Wold]

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!


On 03/21/2012 03:10 PM, Kamble, Nitin A wrote:
>> -----Original Message-----
>> From: Eric Bénard [mailto:eric@eukrea.com]
>> Sent: Wednesday, March 21, 2012 3:05 PM
>> To: Kamble, Nitin A
>> Cc: Martin Jansa; openembedded-core@lists.openembedded.org;
>> richard.purdie@linuxfoundation.org
>> Subject: Re: [PATCH 1/1] Revert "gdb-cross-canadian: build gdb with
>> python support"
>>
>> Le Wed, 21 Mar 2012 21:53:10 +0000,
>> "Kamble, Nitin A"<nitin.a.kamble@intel.com>  a écrit :
>>>   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.
>>
>>> [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.
>>>
>> 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
>>
>> --
>> http://eukrea.com/en/news/104-2012
>
>
> Looks like in my case the sdk gdb is not dynamically linked with libpython.
>
> Nitin
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

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

[Kamble, Nitin A]

 
> 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"

[Eric Bénard]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

Hi Saul,

Le Wed, 21 Mar 2012 15:21:12 -0700,
Saul Wold <sgw@linux.intel.com> a écrit :
> 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

[-- Attachment #2: log.do_compile.gz --]
[-- Type: application/x-gzip, Size: 32063 bytes --]

[-- Attachment #3: log.do_configure --]
[-- Type: application/octet-stream, Size: 8990 bytes --]

DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common']
configure.ac:33: error: Please use exactly Autoconf 2.64 instead of 2.68.
config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:33: the top level
autom4te: m4 failed with exit status: 1
NOTE: Running /home/ebenard//OE-CORE/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/gdb-cross-canadian-i586-7.4-r6.3/gdb-7.4/configure  --build=x86_64-linux 		  --host=x86_64-oesdk-linux 		  --target=i586-oe-linux 		  --prefix=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr 		  --exec_prefix=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr 		  --bindir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/i586-oe-linux 		  --sbindir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/i586-oe-linux 		  --libexecdir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/i586-oe-linux 		  --datadir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/share 		  --sysconfdir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/etc 		  --sharedstatedir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/com 		  --localstatedir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/var 		  --libdir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/i586-oe-linux 		  --includedir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/include 		  --oldincludedir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/include 		  --infodir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/share/info 		  --mandir=/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/share/man 		  --disable-silent-rules 		  --disable-dependency-tracking 		  --with-libtool-sysroot=/home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-linux --disable-gdbtk --disable-tui --disable-x                 --with-curses --disable-multilib --with-system-readline --disable-sim                 --program-prefix='i586-oe-linux-' --with-expat                                 --with-python=/home/ebenard//OE-CORE/build/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/gdb-cross-canadian-i586-7.4-r6.3/python 
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-oesdk-linux-gnu
checking target system type... i586-oe-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for x86_64-oesdk-linux-gcc... ccache x86_64-oesdk-linux-gcc  --sysroot=/home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-linux
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether ccache x86_64-oesdk-linux-gcc  --sysroot=/home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-linux accepts -g... yes
checking for ccache x86_64-oesdk-linux-gcc  --sysroot=/home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-linux option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether ccache x86_64-oesdk-linux-g++  --sysroot=/home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-linux accepts -g... yes
checking for x86_64-oesdk-linux-gnatbind... no
checking for gnatbind... no
checking for x86_64-oesdk-linux-gnatmake... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for objdir... .libs
checking for PWL_handle_timeout in -lpwl... no
checking for version 0.11 (revision 0 or later) of PPL... no
*** This configuration is not supported in the following subdirectories:
     sim
    (Any other directories should still work fine.)
checking for default BUILD_CONFIG... 
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... no
checking for runtest... no
checking for ar... (cached) x86_64-oesdk-linux-ar
checking for x86_64-oesdk-linux-ar... (cached) x86_64-oesdk-linux-ar
checking for as... (cached) x86_64-oesdk-linux-as
checking for x86_64-oesdk-linux-as... (cached) x86_64-oesdk-linux-as
checking for x86_64-oesdk-linux-dlltool... no
checking for ld... (cached) x86_64-oesdk-linux-ld --sysroot=/home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-linux
checking for x86_64-oesdk-linux-ld... (cached) x86_64-oesdk-linux-ld --sysroot=/home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-linux
checking for x86_64-oesdk-linux-lipo... no
checking for nm... (cached) x86_64-oesdk-linux-nm
checking for x86_64-oesdk-linux-nm... (cached) x86_64-oesdk-linux-nm
checking for ranlib... (cached) x86_64-oesdk-linux-ranlib
checking for x86_64-oesdk-linux-ranlib... (cached) x86_64-oesdk-linux-ranlib
checking for strip... (cached) x86_64-oesdk-linux-strip
checking for x86_64-oesdk-linux-strip... (cached) x86_64-oesdk-linux-strip
checking for x86_64-oesdk-linux-windres... no
checking for x86_64-oesdk-linux-windmc... no
checking for objcopy... (cached) x86_64-oesdk-linux-objcopy
checking for x86_64-oesdk-linux-objcopy... (cached) x86_64-oesdk-linux-objcopy
checking for objdump... (cached) x86_64-oesdk-linux-objdump
checking for x86_64-oesdk-linux-objdump... (cached) x86_64-oesdk-linux-objdump
checking for x86_64-oesdk-linux-readelf... x86_64-oesdk-linux-readelf
checking for i586-oe-linux-cc... no
checking for i586-oe-linux-gcc... i586-oe-linux-gcc
checking for i586-oe-linux-c++... i586-oe-linux-c++
checking for i586-oe-linux-gcc... i586-oe-linux-gcc
checking for i586-oe-linux-gcj... no
checking for i586-oe-linux-gfortran... no
checking for i586-oe-linux-gccgo... no
checking for i586-oe-linux-dlltool... no
checking for i586-oe-linux-lipo... no
checking for i586-oe-linux-readelf... i586-oe-linux-readelf
checking for i586-oe-linux-windres... no
checking for i586-oe-linux-windmc... no
checking where to find the target ar... pre-installed in /home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.6.4
checking where to find the target as... pre-installed in /home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.6.4
checking where to find the target cc... pre-installed
checking where to find the target c++... pre-installed
checking where to find the target c++ for libstdc++... pre-installed
checking where to find the target dlltool... pre-installed
checking where to find the target gcc... pre-installed
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... pre-installed
checking where to find the target gccgo... pre-installed
checking where to find the target ld... pre-installed in /home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.6.4
checking where to find the target lipo... pre-installed
checking where to find the target nm... pre-installed in /home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.6.4
checking where to find the target objdump... pre-installed in /home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.6.4
checking where to find the target ranlib... pre-installed in /home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/i586-oe-linux/gcc/i586-oe-linux/4.6.4
checking where to find the target readelf... pre-installed
checking where to find the target strip... pre-installed in /home/ebenard//OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexNOTE: Checking autotools environment for common misconfiguration
NOTE: gdb-cross-canadian-i586: md5 checksum matched for file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552
NOTE: gdb-cross-canadian-i586: md5 checksum matched for file://COPYING.LIB;md5=9f604d8a4f8e74f4f5140845a21b6674
NOTE: gdb-cross-canadian-i586: md5 checksum matched for file://COPYING3;md5=d32239bcb673463ab874e80d47fae504
NOTE: gdb-cross-canadian-i586: md5 checksum matched for file://COPYING3.LIB;md5=6a6a8e020838b23406c81b19c1d46df6
ec/i586-oe-linux/gcc/i586-oe-linux/4.6.4
checking where to find the target windres... pre-installed
checking where to find the target windmc... pre-installed
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether -fkeep-inline-functions is supported... yes
configure: creating ./config.status
config.status: creating Makefile

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

[Kamble, Nitin A]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

Eric, Saul,
   Gdb-cross-canadian build logs from my build attached.
Nitin

> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> 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,
> 
> Le Wed, 21 Mar 2012 15:21:12 -0700,
> Saul Wold <sgw@linux.intel.com> a écrit :
> > 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

[-- Attachment #2: gdb-cross-canadian.tar.bz2 --]
[-- Type: application/octet-stream, Size: 52466 bytes --]

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

[Kamble, Nitin A]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

And the config.log from the builddir is attached to this email.

Thanks,
Nitin


> -----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.
> Nitin
> 
> > -----Original Message-----
> > From: Eric Bénard [mailto:eric@eukrea.com]
> > 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,
> >
> > Le Wed, 21 Mar 2012 15:21:12 -0700,
> > Saul Wold <sgw@linux.intel.com> a écrit :
> > > 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

[-- Attachment #2: config.log.gz --]
[-- Type: application/x-gzip, Size: 7578 bytes --]

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

[Kamble, 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


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"

[Richard Purdie]

Sorry 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"

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

On Mar 21, 2012 2:53 PM, "Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote:
>
> > 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.
>

I think host libs is issue here
Why is libexpat libreadline libz being used from build host

>
> Nitin
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[-- Attachment #2: Type: text/html, Size: 3362 bytes --]

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

[Kamble, Nitin A]

[-- Attachment #1: Type: text/plain, Size: 4120 bytes --]

> [nitin@nbuild0 oecore-x86_64]$ ./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
> *** glibc detected *** ./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb: double free or corruption (out): 0x00007f3226818030 ***
> Aborted (core dumped)
> [nitin@nbuild0 oecore-x86_64]$ ldd ./sysroots/x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb
>        linux-vdso.so.1 =>  (0x00007fffd05d8000)
>        libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003f07400000)
>        libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007fa207a72000)
>        libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007fa20784f000)
>        libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007fa207628000)
>        libz.so.1 => /lib64/libz.so.1 (0x0000003f06c00000)
>        libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007fa2073a5000)
>        libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007fa207188000)
>        libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007fa206f84000)
>        libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003f09800000)
>        libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007fa206bfd000)
>        /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000003f05000000)
>
>
> I am seeing that the sdk gdb is dynamically linking with some of the host libraries as seen above.
>

I think host libs is issue here
Why is libexpat libreadline libz being used from build host



I think there are multiple issues here.  You are right about the incorrect dynamic linking with host libraries. If I run the nativesdk on the build machine, then I don’t see these linking issues, but still gdb core dumps:

$ ldd ./x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb

        linux-vdso.so.1 =>  (0x00007fff4b3f2000)

        libreadline.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libreadline.so.6 (0x00007f71c8336000)

        libdl.so.2 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libdl.so.2 (0x00007f71c8132000)

        libncurses.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libncurses.so.5 (0x00007f71c7f0f000)

        libtinfo.so.5 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libtinfo.so.5 (0x00007f71c7ce8000)

        libz.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libz.so.1 (0x00007f71c7ad3000)

        libm.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libm.so.6 (0x00007f71c7851000)

        libpthread.so.0 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libpthread.so.0 (0x00007f71c7634000)

        libutil.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libutil.so.1 (0x00007f71c7431000)

        libexpat.so.1 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libexpat.so.1 (0x00007f71c7208000)

        libc.so.6 => /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6 (0x00007f71c6e81000)

        /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2 (0x00007f71c8576000)



$ ./x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb

*** glibc detected *** ./x86_64-oesdk-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-gdb: double free or corruption (out): 0x00007f1eaf7f4030 ***



Actually we noticed that Eric’s working sdk gdb was getting linked with the host libpython.so, And if it is linked with the sdk libpython.so then he is able to see same issue what I am seeing.

So look like issue is in the generated libpython.so.

And in failing case, somehow ldd is not reporting that sdk gdb is dynamically linked with libpython.so. That is also strange.

Thanks,

Nitin





[-- Attachment #2: Type: text/html, Size: 10516 bytes --]

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

[Khem Raj]

On Wed, Mar 21, 2012 at 6:58 PM, Kamble, Nitin A
<nitin.a.kamble@intel.com> wrote:
> 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.

> Thanks,

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

[Kamble, Nitin A]

> -----Original Message-----
> From: Khem Raj [mailto:raj.khem@gmail.com]
> 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"
> 
> On Wed, Mar 21, 2012 at 6:58 PM, Kamble, Nitin A
> <nitin.a.kamble@intel.com> wrote:
> > 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.
> 

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"

[Khem Raj]

On Wed, Mar 21, 2012 at 9:55 PM, Kamble, Nitin A
<nitin.a.kamble@intel.com> wrote:
>> On Wed, Mar 21, 2012 at 6:58 PM, Kamble, Nitin A
>> <nitin.a.kamble@intel.com> wrote:
>> > 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.
>>
>
> 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"

[Khem Raj]

On Wed, Mar 21, 2012 at 10:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, Mar 21, 2012 at 9:55 PM, Kamble, Nitin A
> <nitin.a.kamble@intel.com> wrote:
>>> On Wed, Mar 21, 2012 at 6:58 PM, Kamble, Nitin A
>>> <nitin.a.kamble@intel.com> wrote:
>>> > 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.
>>>
>>
>> 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

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"

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 9391 bytes --]

On Wed, Mar 21, 2012 at 11:05:14PM +0100, Eric Bénard wrote:
> Le Wed, 21 Mar 2012 21:53:10 +0000,
> "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> >  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)


> 
> > [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.
> > 
> 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
> 
> -- 
> http://eukrea.com/en/news/104-2012

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Eric Bénard]

Le Thu, 22 Mar 2012 09:47:33 +0100,
Martin Jansa <martin.jansa@gmail.com> a écrit :

> On Wed, Mar 21, 2012 at 11:05:14PM +0100, Eric Bénard wrote:
> > Le Wed, 21 Mar 2012 21:53:10 +0000,
> > "Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
> > >  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"

[Eric Bénard]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

Hi,

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

[-- Attachment #2: sdk_gdb_log.txt --]
[-- Type: text/plain, Size: 4646 bytes --]

$ 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"

[Eric Bénard]

Hi Khem,

Le Wed, 21 Mar 2012 22:06:41 -0700,
Khem Raj <raj.khem@gmail.com> a écrit :
> 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"

[Khem Raj]

On Thu, Mar 22, 2012 at 5:13 AM, Eric Bénard <eric@eukrea.com> wrote:
>
> 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"

[Eric Bénard]

Hi Khem,

Le Thu, 22 Mar 2012 05:17:20 -0700,
Khem Raj <raj.khem@gmail.com> a écrit :

> On Thu, Mar 22, 2012 at 5:13 AM, Eric Bénard <eric@eukrea.com> wrote:
> >
> > 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"

[Khem Raj]

On Thu, Mar 22, 2012 at 5:43 AM, Eric Bénard <eric@eukrea.com> wrote:
> 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"

[Eric Bénard]

Le Thu, 22 Mar 2012 05:57:46 -0700,
Khem Raj <raj.khem@gmail.com> a écrit :

> On Thu, Mar 22, 2012 at 5:43 AM, Eric Bénard <eric@eukrea.com> wrote:
> > 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.

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"

[Eric Bénard]

Le Thu, 22 Mar 2012 14:14:55 +0100,
Eric Bénard <eric@eukrea.com> a écrit :
> [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
> 
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"

[Khem Raj]

On Thu, Mar 22, 2012 at 6:34 AM, Eric Bénard <eric@eukrea.com> wrote:
>
> Le Thu, 22 Mar 2012 14:14:55 +0100,
> Eric Bénard <eric@eukrea.com> a écrit :
>> [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
>>
> 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


>
> Eric
>

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

[Kamble, Nitin A]

> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> 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"
> 
> Le Thu, 22 Mar 2012 05:57:46 -0700,
> Khem Raj <raj.khem@gmail.com> a écrit :
> 
> > On Thu, Mar 22, 2012 at 5:43 AM, Eric Bénard <eric@eukrea.com> wrote:
> > > 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.
> 
> 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

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"

[Khem Raj]

On Thu, Mar 22, 2012 at 9:20 AM, Kamble, Nitin A
<nitin.a.kamble@intel.com> wrote:
>
> 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"

[Kamble, Nitin A]

> -----Original Message-----
> From: Khem Raj [mailto:raj.khem@gmail.com]
> 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"
> 
> On Thu, Mar 22, 2012 at 9:20 AM, Kamble, Nitin A
> <nitin.a.kamble@intel.com> wrote:
> >
> > 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

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"

[Khem Raj]

On Thu, Mar 22, 2012 at 10:38 AM, Kamble, Nitin A
<nitin.a.kamble@intel.com> wrote:
>> On Thu, Mar 22, 2012 at 9:20 AM, Kamble, Nitin A
>> <nitin.a.kamble@intel.com> wrote:
>> >
>> > 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
>
> 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

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"

[Eric Bénard]

Hi Khem, Hi Nitin,

Le Thu, 22 Mar 2012 12:16:44 -0700,
Khem Raj <raj.khem@gmail.com> a écrit :
> On Thu, Mar 22, 2012 at 10:38 AM, Kamble, Nitin A
> <nitin.a.kamble@intel.com> wrote:
> > 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
> 
> 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_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"

[Kamble, Nitin A]

> -----Original Message-----
> From: Eric Bénard [mailto:eric@eukrea.com]
> 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,
> 
> Le Thu, 22 Mar 2012 12:16:44 -0700,
> Khem Raj <raj.khem@gmail.com> a écrit :
> > On Thu, Mar 22, 2012 at 10:38 AM, Kamble, Nitin A
> > <nitin.a.kamble@intel.com> wrote:
> > > 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
> >
> > 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_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


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"

[Kamble, Nitin A]

Khem,
  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"

[Khem Raj]

On 03/22/2012 02:48 PM, Kamble, Nitin A wrote:
>    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"

[Khem Raj]

On 03/22/2012 02:31 PM, Eric Bénard wrote:
> Hi Khem, Hi Nitin,
>
> Le Thu, 22 Mar 2012 12:16:44 -0700,
> Khem Raj<raj.khem@gmail.com>  a écrit :
>> On Thu, Mar 22, 2012 at 10:38 AM, Kamble, Nitin A
>> <nitin.a.kamble@intel.com>  wrote:
>>> 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
>>
>> 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_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

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"

[Khem Raj]

On 03/22/2012 02:31 PM, Eric Bénard wrote:
> Hi Khem, Hi Nitin,
>
> Le Thu, 22 Mar 2012 12:16:44 -0700,
> Khem Raj<raj.khem@gmail.com>  a écrit :
>> On Thu, Mar 22, 2012 at 10:38 AM, Kamble, Nitin A
>> <nitin.a.kamble@intel.com>  wrote:
>>> 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
>>
>> 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_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

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"

[Eric Bénard]

Hi,

Le Thu, 22 Mar 2012 21:40:20 +0000,
"Kamble, Nitin A" <nitin.a.kamble@intel.com> a écrit :
>   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 ;-)

> 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"

[Eric Bénard]

Hi Khem,

Le Fri, 23 Mar 2012 00:12:25 -0700,
Khem Raj <raj.khem@gmail.com> a écrit :
> 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
> 
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"

[Khem Raj]

On 03/23/2012 01:31 AM, Eric Bénard wrote:
> Hi Khem,
>
> Le Fri, 23 Mar 2012 00:12:25 -0700,
> Khem Raj<raj.khem@gmail.com>  a écrit :
>> 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
>>
> 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

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"

[Kamble, Nitin A]

> -----Original Message-----
> From: Khem Raj [mailto:raj.khem@gmail.com]
> 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"
> 
> On 03/23/2012 01:31 AM, Eric Bénard wrote:
> > Hi Khem,
> >
> > Le Fri, 23 Mar 2012 00:12:25 -0700,
> > Khem Raj<raj.khem@gmail.com>  a écrit :
> >> 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
> >>
> > 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
> 
> 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"

[Khem Raj]

On Fri, Mar 23, 2012 at 10:44 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> but then add:
> -Wl,-rpath,${libdir}/.. -Wl,-O1 \
>
> which is:
>
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr
>
> (i.e. without the /lib on the end?) ?

for (sdk atleast cross toolchain bits) libdir points to
${libdir}/arm-oe-gnueabi-linux or whatever the architecture triplet
so using ${libdir}/.. gets us to standard usr/lib

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

[Richard Purdie]

On Fri, 2012-03-23 at 17:01 +0000, Kamble, Nitin A wrote:
> 
> > -----Original Message-----
> > From: Khem Raj [mailto:raj.khem@gmail.com]
> > Sent: Friday, March 23, 2012 9:37 AM
> > To: Kamble, Nitin A
> > Cc: eric; 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"
> > 
> > My patch took care of everything including paths
> > -khem
> > 
> 
> 
> Khem, 
>   I am testing your commit here. From the patch looks like it is taking care of rpath issue for gdb. The rpath issue also needs to be corrected for all the sdk executables.
> And I have this fix for general sdk rpath fix.
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=nitin/sdk-rpath

Er, looking at that patch:

 BUILDSDK_LDFLAGS = "-L${STAGING_LIBDIR} \
 -Wl,-rpath-link,${STAGING_LIBDIR} \
 -Wl,-rpath,${libdir} -Wl,-O1 \
+ -Wl,-rpath,${libdir}/.. -Wl,-O1 \
 -L${STAGING_DIR_HOST}${base_libdir} \
 -Wl,-rpath-link,${STAGING_DIR_HOST}${base_libdir} \
 -Wl,-rpath,${base_libdir} -Wl,-O1"

Things look confused. In the commit message you say:

/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib

but then add:
-Wl,-rpath,${libdir}/.. -Wl,-O1 \

which is:
 
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr

(i.e. without the /lib on the end?) ?

Cheers,

Richard

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

[Kamble, Nitin A]

> -----Original Message-----
> From: Khem Raj [mailto:raj.khem@gmail.com]
> Sent: Friday, March 23, 2012 9:37 AM
> To: Kamble, Nitin A
> Cc: eric; 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"
> 
> My patch took care of everything including paths
> -khem
> 


Khem, 
  I am testing your commit here. From the patch looks like it is taking care of rpath issue for gdb. The rpath issue also needs to be corrected for all the sdk executables.
And I have this fix for general sdk rpath fix.

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=nitin/sdk-rpath

Thanks,
Nitin

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

[Khem Raj]

My patch took care of everything including paths
-khem

"Kamble, Nitin A" <nitin.a.kamble@intel.com> wrote:

>> -----Original Message-----
>> From: Khem Raj [mailto:raj.khem@gmail.com]
>> 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"
>> 
>> On 03/23/2012 01:31 AM, Eric Bénard wrote:
>> > Hi Khem,
>> >
>> > Le Fri, 23 Mar 2012 00:12:25 -0700,
>> > Khem Raj<raj.khem@gmail.com>  a écrit :
>> >> 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
>> >>
>> > 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
>> 
>> 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
>