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

login
mail settings
Submitter Nitin A Kamble
Date March 21, 2012, 4:35 p.m.
Message ID <bfe0a5400cad2436b7be7d35a173c62349e47c0a.1332347414.git.nitin.a.kamble@intel.com>
Download mbox | patch
Permalink /patch/24027/
State New
Headers show

Comments

Nitin A Kamble - March 21, 2012, 4:35 p.m.
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(-)
Eric BENARD - March 21, 2012, 5:07 p.m.
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
Nitin A Kamble - March 21, 2012, 5:47 p.m.
> -----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
Eric BENARD - March 21, 2012, 5:52 p.m.
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
Nitin A Kamble - March 21, 2012, 5:57 p.m.
> -----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
Martin Jansa - March 21, 2012, 5:58 p.m.
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.
Eric BENARD - March 21, 2012, 6:02 p.m.
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
Nitin A Kamble - March 21, 2012, 6:07 p.m.
> -----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
Nitin A Kamble - March 21, 2012, 7:04 p.m.
> 
> 
> 
> > -----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
Eric BENARD - March 21, 2012, 7:32 p.m.
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
Eric BENARD - March 21, 2012, 7:36 p.m.
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
Nitin A Kamble - March 21, 2012, 7:48 p.m.
> -----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
Martin Jansa - March 21, 2012, 7:49 p.m.
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,
Nitin A Kamble - March 21, 2012, 8:48 p.m.
> -----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
Eric BENARD - March 21, 2012, 9:02 p.m.
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
Nitin A Kamble - March 21, 2012, 9:12 p.m.
> -----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
Eric BENARD - March 21, 2012, 9:35 p.m.
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
Nitin A Kamble - March 21, 2012, 9:48 p.m.
> -----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"
Nitin A Kamble - March 21, 2012, 9:53 p.m.
> 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
Nitin A Kamble - March 21, 2012, 10:04 p.m.
Also executing sdk gdb on the same build system (suse) is giving the same error.

Nitin
Eric BENARD - March 21, 2012, 10:05 p.m.
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
Eric BENARD - March 21, 2012, 10:09 p.m.
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
Nitin A Kamble - March 21, 2012, 10:10 p.m.
> -----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
Saul Wold - March 21, 2012, 10:21 p.m.
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
>
Nitin A Kamble - March 21, 2012, 10:22 p.m.
> 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
Eric BENARD - March 21, 2012, 10:37 p.m.
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
Nitin A Kamble - March 21, 2012, 10:55 p.m.
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
Nitin A Kamble - March 21, 2012, 11:07 p.m.
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
Nitin A Kamble - March 21, 2012, 11:25 p.m.
> 
> > 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
Richard Purdie - March 21, 2012, 11:29 p.m.
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
Khem Raj - March 22, 2012, 12:27 a.m.
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
Nitin A Kamble - March 22, 2012, 1:58 a.m.
> [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
Khem Raj - March 22, 2012, 4:24 a.m.
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,
Nitin A Kamble - March 22, 2012, 4:55 a.m.
> -----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
Khem Raj - March 22, 2012, 5:06 a.m.
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
Khem Raj - March 22, 2012, 5:42 a.m.
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 ?
Martin Jansa - March 22, 2012, 8:47 a.m.
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
Eric BENARD - March 22, 2012, 8:50 a.m.
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
Eric BENARD - March 22, 2012, 12:09 p.m.
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
$ 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)
Eric BENARD - March 22, 2012, 12:13 p.m.
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
Khem Raj - March 22, 2012, 12:17 p.m.
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
Eric BENARD - March 22, 2012, 12:43 p.m.
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
Khem Raj - March 22, 2012, 12:57 p.m.
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.
Eric BENARD - March 22, 2012, 1:14 p.m.
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
Eric BENARD - March 22, 2012, 1:34 p.m.
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
Khem Raj - March 22, 2012, 1:54 p.m.
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
>
Nitin A Kamble - March 22, 2012, 4:20 p.m.
> -----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
Khem Raj - March 22, 2012, 4:38 p.m.
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
Nitin A Kamble - March 22, 2012, 5:38 p.m.
> -----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
Khem Raj - March 22, 2012, 7:16 p.m.
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.
Eric BENARD - March 22, 2012, 9:31 p.m.
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
Nitin A Kamble - March 22, 2012, 9:40 p.m.
> -----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
Nitin A Kamble - March 22, 2012, 9:48 p.m.
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
Khem Raj - March 23, 2012, 5:33 a.m.
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.
Khem Raj - March 23, 2012, 6:29 a.m.
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'
Khem Raj - March 23, 2012, 7:12 a.m.
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
Eric BENARD - March 23, 2012, 8:07 a.m.
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
Eric BENARD - March 23, 2012, 8:31 a.m.
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
Khem Raj - March 23, 2012, 12:07 p.m.
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
Nitin A Kamble - March 23, 2012, 4:07 p.m.
> -----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

Patch

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"