Re: [OE-core] [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE

[Kamble, Nitin A]

> > +# nullify -O2
> 
> Can we specify why this is being done here in the recipe? We do this in
> other areas, something like:
> 
> # GCC 4.6.0 hits an internal compiler error using -O2
> # use -O to workaround.
Darren, 
  Good Point, I will update the comment in the tree.

> 
> This make it obvious when looking just at the source why this is an
> issue, and will trigger a retest and removal when we move past 4.6.0.
> Also, if there is a bug number, linking that here would make it easy to
> determine if a fix is ready.


The bug id is in the commit message. Maybe the create_pull_request can create 
the clickable URLs in the email based on that information.

Thanks,
Nitin


> 
> > +CFLAGS_append += " -O"
> 
> Thanks,
> 
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel

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

Re: [OE-core] [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Thursday, May 26, 2011 5:37 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
> 
> On Thu, May 26, 2011 at 4:33 PM, Richard Purdie
>  wrote:
> > On Thu, 2011-05-26 at 13:41 -0700, nitin.a.kam...@intel.com wrote:
> >
> >> ---
> >>  meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb |    3 +++
> >>  1 files changed, 3 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb
> b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb
> >> index b77df2c..051bd72 100644
> >> --- a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb
> >> +++ b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb
> >> @@ -17,3 +17,6 @@ PE = "1"
> >>  PR = "r0"
> >>
> >>  EXTRA_OECONF += "--with-driver=xlib"
> >> +
> >> +# nullify -O2
> >> +CFLAGS_append += " -O"
> >
> > I talked about this on IRC but simply put, no way.
> >
> > The problem is:
> >
> > a) Arm specific
> > b) determined now to be armv7 specific
> > c) gcc version specific
> >
> > and the fix should reflect this.
> >
> > So ideally when we select gcc 4.6 in tcmode-default.inc we should add
> > something there which adds a work around for mesa-xlib.
> >
> > I've suggested something like:
> >
> > TARGET_CC_ARCH_arm_pn-mesa-xlib :=
> "${@'${TARGET_CC_ARCH}'.replace('armv7','armv5')}"
> >
> > which whilst ugly, should do what we need it to.
> >
> 
> I agree with this solution however ugly it may look like. We may
> document it to explain
> the ugliness

This commit wentin yocto branch 
http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=9bccbc5fbc71b331911b558a2ba15e0a6d0046b4

With this documentation:
+# Temporary workaround for gcc 4.6.0 ICE with beagleboard
+# gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47719
+TARGET_CC_ARCH_arm_pn-mesa-xlib := 
"${@'${TARGET_CC_ARCH}'.replace('armv7-a','armv5')}"
+

Thanks,
Nitin

> 
> > Cheers,
> >
> > Richard
> >
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE

[Kamble, Nitin A]

Phil,
  With your patch gcc 4.6.0 is not hitting the internal compiler error for this 
particular case. I could not do runtime testing as I don't have the hw. IMO 
This is a good patch to send to gcc upstream.

Thanks,
Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Friday, May 27, 2011 8:07 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
> 
> On Fri, 2011-05-27 at 00:33 +0100, Richard Purdie wrote:
> > I talked about this on IRC but simply put, no way.
> >
> > The problem is:
> >
> > a) Arm specific
> > b) determined now to be armv7 specific
> > c) gcc version specific
> >
> > and the fix should reflect this.
> 
> From a fairly superficial look at the crash I suspect you probably want
> something like:
> 
> --- arm.md~   2011-05-27 15:18:31.916926254 +0100
> +++ arm.md2011-05-27 15:31:57.331525688 +0100
> @@ -4213,7 +4213,9 @@
> uxth%?\\t%0, %1
> ldr%(h%)\\t%0, %1"
>[(set_attr "type" "alu_shift,load_byte")
> -   (set_attr "predicable" "yes")]
> +   (set_attr "predicable" "yes")
> +   (set_attr "pool_range" "*,256")
> +   (set_attr "neg_pool_range" "*,244")]
>  )
> 
>  (define_insn "*arm_zero_extendhisi2addsi"
> 
> It also looks like this could happen on ARMv6 as well, for what that's
> worth, though I haven't tested to see whether it actually does or not.
> 
> p.
> 
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH] libtirpc: Upgrade 0.2.1 -> 0.2.2

[Kamble, Nitin A]

Hi Khem,
  I am trying to use glibc 2.14 for x32 work, And if you have a working libc 
2.14 recipe, I would like to try it out.

Thanks,
Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Thursday, June 23, 2011 3:40 PM
> To: OE core
> Subject: [OE-core] [PATCH] libtirpc: Upgrade 0.2.1 -> 0.2.2
> 
> Additionally bring in the nis headers which will be
> required when using eglibc 2.14 where rpc support
> is removed.
> 
> Make it provide virtual/librpc
> 
> Signed-off-by: Khem Raj 
> ---
>  .../libtirpc-0.2.2/libtirpc-0.2.1-fortify.patch|   26
> +
>  .../libtirpc-0.2.2-rpc-des-prot.patch  |   39
> 
>  .../libtirpc/libtirpc-0.2.2/remove-des-crypt.patch |   17 +
>  meta/recipes-extended/libtirpc/libtirpc_0.2.1.bb   |   21 ---
>  meta/recipes-extended/libtirpc/libtirpc_0.2.2.bb   |   33
> +
>  5 files changed, 115 insertions(+), 21 deletions(-)
>  create mode 100644 meta/recipes-extended/libtirpc/libtirpc-
> 0.2.2/libtirpc-0.2.1-fortify.patch
>  create mode 100644 meta/recipes-extended/libtirpc/libtirpc-
> 0.2.2/libtirpc-0.2.2-rpc-des-prot.patch
>  create mode 100644 meta/recipes-extended/libtirpc/libtirpc-
> 0.2.2/remove-des-crypt.patch
>  delete mode 100644 meta/recipes-extended/libtirpc/libtirpc_0.2.1.bb
>  create mode 100644 meta/recipes-extended/libtirpc/libtirpc_0.2.2.bb
> 
> diff --git a/meta/recipes-extended/libtirpc/libtirpc-0.2.2/libtirpc-
> 0.2.1-fortify.patch b/meta/recipes-extended/libtirpc/libtirpc-
> 0.2.2/libtirpc-0.2.1-fortify.patch
> new file mode 100644
> index 000..32644b5
> --- /dev/null
> +++ b/meta/recipes-extended/libtirpc/libtirpc-0.2.2/libtirpc-0.2.1-
> fortify.patch
> @@ -0,0 +1,26 @@
> +Fix a possible overflow (reported by _FORTIFY_SOURCE=2)
> +
> +Ported from Gentoo
> +
> +Upstream-Status: Unknown
> +
> +Signed-off-by: Khem Raj 
> +
> +Index: libtirpc-0.2.1/src/getrpcport.c
> +===
> +--- libtirpc-0.2.1.orig/src/getrpcport.c
>  libtirpc-0.2.1/src/getrpcport.c
> +@@ -54,11 +54,11 @@ getrpcport(host, prognum, versnum, proto
> +
> + if ((hp = gethostbyname(host)) == NULL)
> + return (0);
> ++if (hp->h_length != sizeof(addr.sin_addr.s_addr))
> ++return (0);
> + memset(&addr, 0, sizeof(addr));
> + addr.sin_family = AF_INET;
> + addr.sin_port =  0;
> +-if (hp->h_length > sizeof(addr))
> +-  hp->h_length = sizeof(addr);
> + memcpy(&addr.sin_addr.s_addr, hp->h_addr, (size_t)hp->h_length);
> + /* Inconsistent interfaces need casts! :-( */
> + return (pmap_getport(&addr, (u_long)prognum, (u_long)versnum,
> diff --git a/meta/recipes-extended/libtirpc/libtirpc-0.2.2/libtirpc-
> 0.2.2-rpc-des-prot.patch b/meta/recipes-extended/libtirpc/libtirpc-
> 0.2.2/libtirpc-0.2.2-rpc-des-prot.patch
> new file mode 100644
> index 000..c38a55b
> --- /dev/null
> +++ b/meta/recipes-extended/libtirpc/libtirpc-0.2.2/libtirpc-0.2.2-rpc-
> des-prot.patch
> @@ -0,0 +1,39 @@
> +From f2f43212b33dea42635061c82645287454a70107 Mon Sep 17 00:00:00 2001
> +From: Mike Frysinger 
> +Date: Sat, 11 Jun 2011 15:21:55 -0400
> +Subject: [PATCH] add multiple inclusion protection to rpc/des.h
> +
> +If you try to include this file multiple times, you get a build
> failure
> +due to redefinitions of enums and such.
> +
> +Signed-off-by: Mike Frysinger 
> +---
> + tirpc/rpc/des.h |5 +
> + 1 files changed, 5 insertions(+), 0 deletions(-)
> +
> +
> +Upstream-Status: Backport
> +
> +diff --git a/tirpc/rpc/des.h b/tirpc/rpc/des.h
> +index e3d6897..d2881ad 100644
> +--- a/tirpc/rpc/des.h
>  b/tirpc/rpc/des.h
> +@@ -33,6 +33,9 @@
> +  * Copyright (c) 1986 by Sun Microsystems, Inc.
> +  */
> +
> ++#ifndef _RPC_DES_H_
> ++#define _RPC_DES_H_
> ++
> + #define DES_MAXLEN  65536   /* maximum # of bytes to encrypt  */
> + #define DES_QUICKLEN16  /* maximum # of bytes to encrypt quickly
> */
> +
> +@@ -80,3 +83,5 @@ struct desparams {
> +  * Software DES.
> +  */
> + extern int _des_crypt( char *, int, struct desparams * );
> ++
> ++#endif
> +--
> +1.7.5.3
> +
> diff --git a/meta/recipes-extended/libtirpc/libtirpc-0.2.2/remove-des-
> crypt.patch b/meta/recipes-extended/libtirpc/libtirpc-0.2.2/remove-des-
> crypt.patch
> new file mode 100644
> index 000..d94a585
> --- /dev/null
> +++ b/meta/recipes-extended/libtirpc/libtirpc-0.2.2/remove-des-
> crypt.patch
> @@ -0,0 +1,17 @@
> +http://sourceforge.net/mailarchive/message.php?msg_id=27636466
> +
> +Upstream-Status: Backport
> +
> +Index: libtirpc-0.2.2/src/Makefile.am
> +===
> +--- libtirpc-0.2.2.orig/src/Makefile.am
>  libtirpc-0.2.2/src/Makefile.am
> +@@ -50,7 +50,7 @@ libtirpc_la_SOURCES = auth_none.c auth_u
> + rpc_callmsg.c rpc_generic.c rpc_soc

Re: [OE-core] [PATCH] binutils: allow distro to select gold as default linker

[Kamble, Nitin A]

Good to see that gold is enabled only if distro config requests it. I have some 
need which will need disabling gold.

Thanks,
Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Monday, June 27, 2011 8:51 AM
> To: oe-core
> Subject: [OE-core] [PATCH] binutils: allow distro to select gold as
> default linker
> 
> But ensure that gcc-cross-intermediate always uses ld.bfd since
> (e)glibc won't build with gold.
> 
> Signed-off-by: Phil Blundell 
> ---
>  meta/recipes-devtools/binutils/binutils-cross.inc  |3 ++-
>  .../gcc/gcc-cross-intermediate.inc |7 ++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-devtools/binutils/binutils-cross.inc
> b/meta/recipes-devtools/binutils/binutils-cross.inc
> index 4b90972..5a41970 100644
> --- a/meta/recipes-devtools/binutils/binutils-cross.inc
> +++ b/meta/recipes-devtools/binutils/binutils-cross.inc
> @@ -5,7 +5,8 @@ EXTRA_OECONF = "--with-sysroot=${STAGING_DIR_TARGET} \
>  --program-prefix=${TARGET_PREFIX} \
>  --disable-install-libbfd \
>  --disable-werror \
> ---enable-poison-system-directories"
> +--enable-poison-system-directories \
> + ${@base_contains('DISTRO_FEATURES', 'ld-is-gold', '--
> enable-gold=default', '', d)}"
> 
>  do_install () {
>   oe_runmake 'DESTDIR=${D}' install
> diff --git a/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
> b/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
> index 92c3ce2..05b5dbc 100644
> --- a/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
> +++ b/meta/recipes-devtools/gcc/gcc-cross-intermediate.inc
> @@ -7,6 +7,10 @@ CROSS_TARGET_SYS_DIR_append = ".${PN}"
> 
>  # This is intended to be a -very- basic config
>  # sysroot is needed in case we use libc-initial
> +#
> +# Glibc won't compile with gold, and building glibc is the whole point
> of
> +# this recipe.   So we select ld.bfd explicitly here if gold is the
> distro's
> +# preferred linker.
>  EXTRA_OECONF = "--with-local-
> prefix=${STAGING_DIR_TARGET}${target_prefix} \
>   --enable-shared \
>   --disable-multilib \
> @@ -17,7 +21,8 @@ EXTRA_OECONF = "--with-local-
> prefix=${STAGING_DIR_TARGET}${target_prefix} \
>   --with-sysroot=${STAGING_DIR_TCBOOTSTRAP} \
>   --with-build-sysroot=${STAGING_DIR_TCBOOTSTRAP} \
>   ${EXTRA_OECONF_INTERMEDIATE} \
> - ${@get_gcc_fpu_setting(bb, d)}"
> + ${@get_gcc_fpu_setting(bb, d)} \
> + ${@base_contains('DISTRO_FEATURES', 'ld-is-gold', '--with-
> ld=${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}ld.bfd', '', d)}"
> 
>  do_populate_sysroot[sstate-inputdirs] =
> "${SYSROOT_DESTDIR}/${STAGING_DIR_HOST}
> ${SYSROOT_DESTDIR}/${STAGING_DIR_TARGET}/${target_base_libdir}"
>  do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}
> ${STAGING_DIR_TCBOOTSTRAP}/${target_base_libdir}"
> --
> 1.7.2.5
> 
> 
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 6/8] perl: fix for non /usr/lib libdir case

[Kamble, Nitin A]

Hi Ke, 
   Is this for multilib ?

Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Yu Ke
> Sent: Thursday, July 07, 2011 7:10 AM
> To: openembedded-core@lists.openembedded.org;
> richard.pur...@linuxfoundation.org
> Subject: [OE-core] [PATCH 6/8] perl: fix for non /usr/lib libdir case
> 
> the config.sh is hardcoded to be /usr/lib, which does not work in non
> /usr/lib libdir case.
> 
> This patch replace the hard code /usr/lib with ${libdir} to fix this
> issue
> 
> Signed-off-by: Yu Ke 
> ---
>  meta/recipes-devtools/perl/perl_5.12.3.bb |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/recipes-devtools/perl/perl_5.12.3.bb b/meta/recipes-
> devtools/perl/perl_5.12.3.bb
> index b053482..88dcfdd 100644
> --- a/meta/recipes-devtools/perl/perl_5.12.3.bb
> +++ b/meta/recipes-devtools/perl/perl_5.12.3.bb
> @@ -8,7 +8,7 @@ PRIORITY = "optional"
>  # We need gnugrep (for -I)
>  DEPENDS = "virtual/db grep-native"
>  DEPENDS += "gdbm zlib"
> -PR = "r1"
> +PR = "r2"
> 
>  # 5.10.1 has Module::Build built-in
>  PROVIDES += "libmodule-build-perl"
> @@ -150,6 +150,7 @@ do_configure() {
> -e 's,@ARCH@-thread-multi,,g' \
> -e 's,@ARCH@,${TARGET_ARCH}-${TARGET_OS},g' \
> -e "s%/usr/include%${STAGING_INCDIR}%g" \
> +-e 's,/usr/lib/,${libdir}/,g' \
>  -e 's,/usr/,${exec_prefix}/,g' \
>  -e 's,/perl5,/perl,g' \
>  config.sh-${TARGET_ARCH}-${TARGET_OS}
> --
> 1.7.0.4
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] eglibc issuettes continued

[Kamble, Nitin A]

I sent a patch to fix /etc/localtime & /etc/rpc files. Other than that I am not 
seeing any issues for the eglibc recipe packaging.

Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Friday, July 08, 2011 9:49 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] eglibc issuettes continued
> 
> On Fri, 2011-07-08 at 16:41 +0100, Phil Blundell wrote:
> > I'm not sure whether there are pending patches which will address
> these
> > or not, but with a fresh pull from today I'm still not getting very
> good
> > packaging for eglibc 2.13.  Specifically:
> >
> > WARNING: For recipe eglibc, the following files were installed but
> not
> > shipped in any package:
> > WARNING:   /etc/localtime
> > WARNING:   /etc/rpc
> > WARNING:   /etc/ld.so.conf
> > WARNING:   /lib/gconv/ISO-2022-CN-EXT.so
> > WARNING:   /lib/gconv/IBM921.so
> > [... etc ...]
> > WARNING:   /lib/gconv/.debug/ISO-2022-CN-EXT.so
> > WARNING:   /lib/gconv/.debug/IBM921.so
> > [... etc ...]
> > WARNING:   /share/i18n/charmaps/ISO-8859-15.gz
> > WARNING:   /share/i18n/charmaps/IBM285.gz
> > [... etc ...]
> > WARNING:   /share/i18n/locales/ss_ZA
> > WARNING:   /share/i18n/locales/is_IS
> > [... etc ...]
> > WARNING: QA Issue: libc-extra-nss rdepends on eglibc-dev
> > WARNING: QA Issue: libc-thread-db rdepends on eglibc-dev
> > ERROR: QA run found fatal errors. Please consider fixing them.
> >
> > I'm not sure if these are actually new or not, though.  It's possible
> > that they've been there for ages and I only just noticed.
> 
> I'm guessing something is going wrong with prefixes somewhere. I'm
> certainly not seeing the bulk of those locally...
> 
> Cheers,
> 
> Richard
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 5/7] eglibc: fix installed but not packaged files

[Kamble, Nitin A]

Thanks for clarifications. I will rework the patch to take out the rpc.
Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Thursday, July 07, 2011 2:41 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 5/7] eglibc: fix installed but not
> packaged files
> 
> On Thu, Jul 7, 2011 at 1:42 PM, Phil Blundell  wrote:
> > On Thu, 2011-07-07 at 13:25 -0700, nitin.a.kam...@intel.com wrote:
> >> -FILES_${PN} = "${libc_baselibs} ${libexecdir}/*
> ${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig
> ${sysconfdir}/ld.so.conf', '', d)}"
> >> +FILES_${PN} = "${libc_baselibs} ${libexecdir}/* ${sysconfdir}/rpc
> ${@base_conditional('USE_LDCONFIG', '1', '${base_sbindir}/ldconfig
> ${sysconfdir}/ld.so.conf', '', d)}"
> >
> > I don't think we want /etc/rpc in libc6, it's just a waste of space
> if
> > you aren't using sunrpc.  Nobody has missed it thus far so I would be
> > inclined to delete it, but it could go in a package of its own if
> there
> > is a feeling that it's valuable.
> 
> Moreover sun rpc is now obsolete in glibc 2.14 onwards so probably
> removing it from package is right thing to do.
> >
> > p.
> >
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/7] binutils: package unpackaged files

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Friday, July 08, 2011 8:27 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 4/7] binutils: package unpackaged files
> 
> On Thu, 2011-07-07 at 13:25 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > To fix these package qa warnings
> > WARNING: For recipe binutils, the following files were installed but
> not shipped in any package:
> > WARNING:   /usr/bin/ld.bfd
> > WARNING:   /usr/bin/elfedit
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../binutils/binutils-cross-canadian_2.21.1.bb |2 +-
> >  .../binutils/binutils-crosssdk_2.21.1.bb   |2 +-
> >  meta/recipes-devtools/binutils/binutils.inc|2 ++
> >  meta/recipes-devtools/binutils/binutils_2.21.1.bb  |2 +-
> >  4 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/binutils/binutils-cross-
> canadian_2.21.1.bb b/meta/recipes-devtools/binutils/binutils-cross-
> canadian_2.21.1.bb
> > index 7dad2a6..e91e7dc 100644
> > --- a/meta/recipes-devtools/binutils/binutils-cross-
> canadian_2.21.1.bb
> > +++ b/meta/recipes-devtools/binutils/binutils-cross-
> canadian_2.21.1.bb
> > @@ -1,3 +1,3 @@
> >  require binutils_${PV}.bb
> >  require binutils-cross-canadian.inc
> > -PR = "r0"
> > +PR = "r1"
> > diff --git a/meta/recipes-devtools/binutils/binutils-
> crosssdk_2.21.1.bb b/meta/recipes-devtools/binutils/binutils-
> crosssdk_2.21.1.bb
> > index 0d6efff..21289cd 100644
> > --- a/meta/recipes-devtools/binutils/binutils-crosssdk_2.21.1.bb
> > +++ b/meta/recipes-devtools/binutils/binutils-crosssdk_2.21.1.bb
> > @@ -4,7 +4,7 @@ inherit crosssdk
> >
> >  PROVIDES = "virtual/${TARGET_PREFIX}binutils-crosssdk"
> >
> > -PR = "r0"
> > +PR = "r1"
> >
> >  do_configure_prepend () {
> > sed -i 's#/usr/local/lib /lib /usr/lib#${SDKPATHNATIVE}/lib
> ${SDKPATHNATIVE}/usr/lib /usr/local/lib /lib /usr/lib#'
> ${S}/ld/configure.tgt
> > diff --git a/meta/recipes-devtools/binutils/binutils.inc
> b/meta/recipes-devtools/binutils/binutils.inc
> > index 08c14b2..9a6b9c8 100644
> > --- a/meta/recipes-devtools/binutils/binutils.inc
> > +++ b/meta/recipes-devtools/binutils/binutils.inc
> > @@ -35,11 +35,13 @@ FILES_${PN}-symlinks = " \
> > ${bindir}/c++filt \
> > ${bindir}/gprof \
> > ${bindir}/ld \
> > +   ${bindir}/ld.bfd \
> > ${bindir}/nm \
> > ${bindir}/objcopy \
> > ${bindir}/objdump \
> > ${bindir}/ranlib \
> > ${bindir}/readelf \
> > +   ${bindir}/elfedit \
> > ${bindir}/size \
> > ${bindir}/strip"
> 
> Nitin, do you know if the ld.bfd above is a hardlinked copy of ld?
> 
> It may be better to turn this into a symlink if so (although our
> packaging process should preserve hardlinks these days).
> 
Richard,
   The ld.bfd is softlink to _ld. Hence I put it in the symlinks 
package.
Nitin


> Cheers,
> 
> Richard
> 
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] eglibc issuettes continued

[Kamble, Nitin A]

Richard,
 You can make similar patch for localtime, (which is a broken link), Otherwise 
I will send a patch for it.

Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Friday, July 08, 2011 10:19 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] eglibc issuettes continued
> 
> On Fri, 2011-07-08 at 09:59 -0700, Kamble, Nitin A wrote:
> > I sent a patch to fix /etc/localtime & /etc/rpc files. Other than
> that I am not seeing any issues for the eglibc recipe packaging.
> 
> I pushed:
> 
> http://git.openembedded.net/cgit.cgi/openembedded-
> core/commit/?id=93ce74a299832ca7f24b4ce1b951abffa0232612
> 
> to fix one of those. If there is still the localtime issue, we probably
> need a patch for that one...
> 
> Cheers,
> 
> Richard
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 4/7] binutils: package unpackaged files

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Friday, July 08, 2011 8:34 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 4/7] binutils: package unpackaged files
> 
> On Fri, 2011-07-08 at 16:26 +0100, Richard Purdie wrote:
> > > @@ -35,11 +35,13 @@ FILES_${PN}-symlinks = " \
> > >   ${bindir}/c++filt \
> > >   ${bindir}/gprof \
> > >   ${bindir}/ld \
> > > + ${bindir}/ld.bfd \
> > >   ${bindir}/nm \
> > >   ${bindir}/objcopy \
> > >   ${bindir}/objdump \
> > >   ${bindir}/ranlib \
> > >   ${bindir}/readelf \
> > > + ${bindir}/elfedit \
> > >   ${bindir}/size \
> > >   ${bindir}/strip"
> >
> > Nitin, do you know if the ld.bfd above is a hardlinked copy of ld?
> 
> If you're getting ld.bfd at all (at least with our current recipes)
> then
> it probably means that ${bindir}/ld is gold.  So in that case they
> oughtn't to be symlinked.
> 
Just verified that ld.bfd is a soft link to i586-poky-linux-ld.bfd

So what is the right think here, rm -f ld.bfd, or putting it in the symlinks 
package is good?

Nitin

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

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

Re: [OE-core] [PATCH 2/5] udev-172: add a newer version for newer kernel

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Wednesday, July 13, 2011 12:00 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 2/5] udev-172: add a newer version for
> newer kernel
> 
> 
> Op 13 jul 2011, om 08:22 heeft Khem Raj het volgende geschreven:
> 
> >
> >
> > On Jul 12, 2011, at 12:02 PM, nitin.a.kam...@intel.com wrote:
> >
> >> From: Nitin A Kamble 
> >>
> >> the 2.6.38 kernel has dropped v4lv1 support. and udev-168 fails to
> >> compile because of that. So add a newer 172 version of udev to work
> with
> >> 2.6.38 kernel.
> >>
> >> Signed-off-by: Nitin A Kamble 
> >> ---
> >> meta/recipes-core/udev/udev-172/init  |   59 +
> >> meta/recipes-core/udev/udev-172/local.rules   |   35 ++
> >> meta/recipes-core/udev/udev-172/permissions.rules |  131
> +
> >> meta/recipes-core/udev/udev-172/run.rules |   14 +++
> >> meta/recipes-core/udev/udev-172/udev.rules|  116
> ++
> >> meta/recipes-core/udev/udev_172.bb|6 +
> >> 6 files changed, 361 insertions(+), 0 deletions(-)
> >> create mode 100644 meta/recipes-core/udev/udev-172/init
> >> create mode 100644 meta/recipes-core/udev/udev-172/local.rules
> >> create mode 100644 meta/recipes-core/udev/udev-172/permissions.rules
> >> create mode 100644 meta/recipes-core/udev/udev-172/run.rules
> >> create mode 100644 meta/recipes-core/udev/udev-172/udev.rules
> >> create mode 100644 meta/recipes-core/udev/udev_172.bb
> >
> > Meta-oe ha 171 it would be nice if you could look inti it and
> incorporate any differences into 172
> > Then we can retire 171 from meta-oe
> 
> Meta-oe has had 172 since yesterday :) The main difference between the
> oe-core and meta-oe version is that the meta-oe version has removed a
> lot of udev rules that weren't needed and made booting slow. Where udev
> trigger used to take >8 seconds I can now boot X in less than a second
> on a cortex A9.
> 
> regards,
> 
> Koen

Great, then we can take meta-oe version of 172 into oe-core.

Thanks,
Nitin

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

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

Re: [OE-core] [PATCH 1/5] siteinfo.bbclass: hack for x32

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Tuesday, July 12, 2011 11:20 PM
> To: Patches and discussions about the oe-core layer
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/5] siteinfo.bbclass: hack for x32
> 
> 
> 
> On Jul 12, 2011, at 12:02 PM, nitin.a.kam...@intel.com wrote:
> 
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> > meta/classes/siteinfo.bbclass |3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta/classes/siteinfo.bbclass
> b/meta/classes/siteinfo.bbclass
> > index 78b7008..035355f 100644
> > --- a/meta/classes/siteinfo.bbclass
> > +++ b/meta/classes/siteinfo.bbclass
> > @@ -59,6 +59,9 @@ def get_siteinfo_list(d):
> >"x86_64-linux":"endian-little bit-64
> common-glibc",\
> >"x86_64-linux-uclibc": "endian-little bit-64
> common-uclibc"}
> >if target in targetinfo:
> > +  target_cc_arch = bb.data.getVar('TARGET_CC_ARCH',
> d, 1)
> > +   if target_cc_arch == "-mx32":
> > + target = "i686-linux"
> 
> What would/could target be when using -mx32 ?
> I suppose it's one of the entries in dictionary above
> 
So far x86_64 is the target for x32.

Nitin

> 
> 
> >info = targetinfo[target].split()
> >info.append(target)
> >info.append("common")
> > --
> > 1.7.5.4
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH] gcc-4.6: update to 4.6.1 release

[Kamble, Nitin A]

Has anybody tried building all arches with commit? If it has worked well then 
the upgrade to 4.6.1 is good. Otherwise it may affect too many people.

Thanks,
Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Wednesday, July 13, 2011 9:41 AM
> To: oe-core
> Subject: [OE-core] [PATCH] gcc-4.6: update to 4.6.1 release
> 
> Set SRCREV to match the point at which 4.6.1 was released, update PV
> appropriately.
> 
> Signed-off-by: Phil Blundell 
> ---
>  meta/recipes-devtools/gcc/gcc-4.6.inc |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-
> devtools/gcc/gcc-4.6.inc
> index 56064b5..8af5369 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
> @@ -1,6 +1,6 @@
>  require gcc-common.inc
> 
> -PR = "r8"
> +PR = "r0"
> 
>  # Third digit in PV should be incremented after a minor release
>  # happens from this branch on gcc e.g. currently its 4.6.0
> @@ -8,7 +8,7 @@ PR = "r8"
>  # on branch then PV should be incremented to 4.6.1+svnr${SRCPV}
>  # to reflect that change
> 
> -PV = "4.6.0+svnr${SRCPV}"
> +PV = "4.6.1+svnr${SRCPV}"
> 
>  # BINV should be incremented after updating to a revision
>  # after a minor gcc release (e.g. 4.6.1 or 4.6.2) has been made
> @@ -18,7 +18,7 @@ PV = "4.6.0+svnr${SRCPV}"
> 
>  BINV = "4.6.1"
> 
> -SRCREV = 175150
> +SRCREV = 175454
>  BRANCH = "gcc-4_6-branch"
>  FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.6' ], d)}"
> 
> --
> 1.7.4.1
> 
> 
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 2/2] perl-dynloader.patch: Fix libdir issue for multilib

[Kamble, Nitin A]

> -Original Message-
> From: Mei, Lei
> Sent: Thursday, July 21, 2011 12:54 AM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: RE: [OE-core] [PATCH 2/2] perl-dynloader.patch: Fix libdir
> issue for multilib
> 
> 
> 
> >-Original Message-
> >From: openembedded-core-boun...@lists.openembedded.org
> >[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> >Richard Purdie
> >Sent: Wednesday, July 20, 2011 10:34 PM
> >To: Patches and discussions about the oe-core layer
> >Subject: Re: [OE-core] [PATCH 2/2] perl-dynloader.patch: Fix libdir
> issue for
> >multilib
> >
> >On Wed, 2011-07-20 at 16:48 +0800, Mei Lei wrote:
> >> The perl-dynloader.patch can't support /usr/lib64, change the
> regular
> >expression to support multilib.
> >>
> >> Signed-off-by: Mei Lei 
> >> ---
> >>  .../perl/perl-5.12.3/perl-dynloader.patch  |2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/meta/recipes-devtools/perl/perl-5.12.3/perl-
> dynloader.patch
> >b/meta/recipes-devtools/perl/perl-5.12.3/perl-dynloader.patch
> >> index d5ea00f..a45af91 100644
> >> --- a/meta/recipes-devtools/perl/perl-5.12.3/perl-dynloader.patch
> >> +++ b/meta/recipes-devtools/perl/perl-5.12.3/perl-dynloader.patch
> >> @@ -19,7 +19,7 @@ Update by Nitin A Kamble
> 
> >2011/04/21
> >>  +{
> >>  +my $hostlib = $ENV{PERLHOSTLIB};
> >>  +print STDERR "*** Module name IN: $modlibname\n";
> >> -+($p1, $p2, $p3, $p4, $p5) = $modlibname =~
> >m/(^(.*lib\/)?)((perl\/[0-9\.]*\/)?)(.*)$/;
> >> ++($p1, $p2, $p3, $p4, $p5) = $modlibname =~
> >m/(^(.*lib[0-9]*\/)?)((perl\/[0-9\.]*\/)?)(.*)$/;
> >>  +print STDERR "*** p1: $p1  p3: $p3  p5: $p5\n";
> >>  +if ( $p1 ne "" ) {
> >>  +$modlibname = $hostlib.$p5;
> >
> >We might need to relax this a little further since we might want
> things
> >like libx32 to work in future?
> 
> Hi Nitin,
>   I am not sure what is the perl work style under libx32, can you
> supply some information about it?
> 
> Thanks
> Lei

Hi Lei,
  x32 would use libx32 as the lib dirname.
Thanks,
Nitin
> 
> 
> >
> >Cheers,
> >
> >Richard
> >
> >
> >
> >___
> >Openembedded-core mailing list
> >Openembedded-core@lists.openembedded.org
> >http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 2/2] glib-2.0: fix a compilation issue due to dtrace

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, July 21, 2011 9:00 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 2/2] glib-2.0: fix a compilation issue
> due to dtrace
> 
> On Thu, 2011-07-21 at 02:29 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> 
> Could you add some text to the commit message explaining what the
> compilation issue was and under what circumstances it occurred?  It
> might also be good to know why bumping PR isn't necessary.
> 
Phil,
  I felt the PR bump was not necessary, as it was fixing the compilation issue. 
I will add more information to the commit and resend it.

> Also:
> 
> > diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb
> b/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb
> > index a2e609f..7d095c1 100644
> > --- a/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb
> > +++ b/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb
> > @@ -19,4 +19,3 @@ SRC_URI[md5sum] =
> "789e7520f71c6a4bf08bc683ec764d24"
> >  SRC_URI[sha256sum] =
> "222f3055d6c413417b50901008c654865e5a311c73f0ae918b0a9978d1f9466f"
> >
> >  BBCLASSEXTEND = "native"
> > -
> 
> ... I guess this part of the patch can be omitted.

Noted down.

Thanks,
Nitin

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

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

Re: [OE-core] [PATCH 1/2] python: fix security vulnerability

[Kamble, Nitin A]

> devtools/python/python/security_issue_2254_fix.patch
> > @@ -0,0 +1,184 @@
> > +UpstreamStatus: Backport
> 
> This should be Upstream-Status I guess to match other patches that
> said there are few more anomalies
> 
> meta/recipes-devtools/dosfstools/dosfstools/dosfstools-2.10-kernel-
> 2.6.patch:
> "Upstream Status"
> meta/recipes-devtools/btrfs-tools/btrfs-
> tools/fix_use_of_gcc.patch:UpstreamStatus:
> Pending
> meta/recipes-devtools/elfutils/elfutils/fix_for_gcc-
> 4.7.patch:UpstreamStatus:
> pending
> 

Thanks Khem for catching these. I have sending fixes for these.

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

Re: [OE-core] [PATCH 2/4] siteinfo.bbclass: add entries for new x86_64 ABI targets

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Wednesday, July 27, 2011 4:13 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/4] siteinfo.bbclass: add entries for
> new x86_64 ABI targets
> 
> On 07/27/2011 04:09 PM, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/classes/siteinfo.bbclass |   14 +-
> >  1 files changed, 13 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta/classes/siteinfo.bbclass
> b/meta/classes/siteinfo.bbclass
> > index 9dacd58..daa7946 100644
> > --- a/meta/classes/siteinfo.bbclass
> > +++ b/meta/classes/siteinfo.bbclass
> > @@ -42,12 +42,15 @@ def siteinfo_data(d):
> >  "sh4": "endian-little bit-32 sh-common",
> >  "sparc": "endian-big bit-32",
> >  "viac3": "endian-little bit-32 ix86-common",
> > -"x86_64": "endian-little bit-64",
> > +"x86_64": "endian-little", # bitinfo specified in targetinfo
> >  }
> >  osinfo = {
> >  "darwin": "common-darwin",
> >  "darwin9": "common-darwin",
> >  "linux": "common-linux common-glibc",
> > +"linux-gnu32": "common-linux common-glibc",
> > +"linux-gnux32": "common-linux common-glibc",
> > +"linux-gnu64": "common-linux common-glibc",
> >  "linux-gnueabi": "common-linux common-glibc",
> >  "linux-gnuspe": "common-linux common-glibc",
> >  "linux-uclibc": "common-linux common-uclibc",
> > @@ -68,6 +71,15 @@ def siteinfo_data(d):
> >  "powerpc-linux-uclibcspe": "powerpc-linux powerpc32-linux
> powerpc-linux-uclibc",
> >  "powerpc64-linux-gnuspe": "powerpc-linux powerpc64-linux",
> >  "powerpc64-linux": "powerpc-linux",
> > +"x86_64-cygwin": "bit-64",
> > +"x86_64-darvin": "bit-64",
> > +"x86_64-darvin9": "bit-64",
> 
> dar_v_in? :)
> 
> Slightly more seriously, lets drop out ones we can't / aren't using,
> wrt
> hosts, until we're going to do them for real.

Hi Tom,
  I don't know if they(cygwin, darvin) work or not, I just kept them in the 
same state. If they are not used/working, then it is good to clean them out.

Nitin

> 
> --
> Tom Rini
> Mentor Graphics Corporation
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 2:50 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix
> KERNEL_LD & KERNEL_AR vars
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > KERNEL_LD was using ${LD} in it's definition, which is not correct
> for
> > different ABIs such as x32 or i386 on x86_64 machine.
> >
> > Same with KERNEL_AR var.
> 
> Why is ar an issue?  That doesn't have any unusual args, does it?
> 
> p.

No special args for ar, but The change makes definition of KERNEL_AR consistent 
with other definitions like KERNEL_CC & KERNEL_LD.

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

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

Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 2:51 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> 
> This commit message is very terse.  Why is this change necessary?

Because meta-x32 layer has glibc, which needs these support files. I will 
update the commit message in the tree.
Thanks,
Nitin

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

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

Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 2:57 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> tune parameters
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> >  # ELF32 ABI
> >  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> > -TUNECONFLICTS[m32] = "m64"
> > +TUNECONFLICTS[m32] = "m64 mx32"
> >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "${X86ARCH32}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32",
> "" ,d)}"
> >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
> "", d)}"
> 
> This is going to cause TARGET_OS to change for everyone using the i586
> ABI, right?  That doesn't seem like it is either necessary or
> desirable,
> and it isn't mentioned in the checkin comment either.

Correct, this will change the TARGET_OS from linux_gnu to linux_gnu32. And it 
is also applicable for x86-64 machine set with x86 tune. This change is be 
needed if multiple tunes are built from the same build directory. If such 
situation is not important then the ABIEXTENSION part can be dropped.

> 
> >  # ELF64 ABI 
> >  TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> > -TUNECONFLICT[m64] = "m32"
> > +TUNECONFLICT[m64] = "m32 mx32"
> >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> "${X86ARCH64}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64",
> "" ,d)}"
> >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64",
> "", d)}"
> 
> ... and likewise this for anybody using the x86-64 ABI.
This is similar to above.

> 
> > -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
> > +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"
> 
> That change might well be fine, but again it isn't mentioned in the
> checkin message.
This is making this consistent with other PACKAGE_EXTRA_ARCHS_tune convention 
elsewhere. I will update the commit message for this.

> 
> > diff --git a/meta/conf/machine/include/tune-x86_64.inc
> b/meta/conf/machine/include/tune-x86_64.inc
> > index 04b0f96..50f20ba 100644
> > --- a/meta/conf/machine/include/tune-x86_64.inc
> > +++ b/meta/conf/machine/include/tune-x86_64.inc
> > @@ -1,3 +1,3 @@
> >  require conf/machine/include/ia32/arch-ia32.inc
> >
> > -DEFAULTTUNE = "x86-64"
> > +DEFAULTTUNE ?= "x86-64"
> 
> This one is also not mentioned in the checkin message and looks a bit
> more dubious to me.  Why is this required?
> 
It was required at one point when multilist support was quiet unstable. The 
reason it is done because the arch-ia32.inc file is included for both x86, 
tune-core, & x86-64 and setting this hard assignment, was breaking x86 or x32 
targets. Not sure if it is still needed, I will check it.

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

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

Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> >
> > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> > >  # ELF32 ABI
> > >  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> > > -TUNECONFLICTS[m32] = "m64"
> > > +TUNECONFLICTS[m32] = "m64 mx32"
> > >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> > "${X86ARCH32}", "" ,d)}"
> > > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "32",
> > "" ,d)}"
> > >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-
> m32",
> > "", d)}"
> >
> > This is going to cause TARGET_OS to change for everyone using the
> i586
> > ABI, right?  That doesn't seem like it is either necessary or
> > desirable,
> > and it isn't mentioned in the checkin comment either.
> 
> Correct, this will change the TARGET_OS from linux_gnu to linux_gnu32.
> And it is also applicable for x86-64 machine set with x86 tune. This
> change is be needed if multiple tunes are built from the same build
> directory. If such situation is not important then the ABIEXTENSION
> part can be dropped.
> 
> >
> > >  # ELF64 ABI
> > >  TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> > > -TUNECONFLICT[m64] = "m32"
> > > +TUNECONFLICT[m64] = "m32 mx32"
> > >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> > "${X86ARCH64}", "" ,d)}"
> > > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> "64",
> > "" ,d)}"
> > >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-
> m64",
> > "", d)}"
> >
> > ... and likewise this for anybody using the x86-64 ABI.
> This is similar to above.
> 
> >
> > > -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
> > > +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"
> >
> > That change might well be fine, but again it isn't mentioned in the
> > checkin message.
> This is making this consistent with other PACKAGE_EXTRA_ARCHS_tune
> convention elsewhere. I will update the commit message for this.
> 
> >
> > > diff --git a/meta/conf/machine/include/tune-x86_64.inc
> > b/meta/conf/machine/include/tune-x86_64.inc
> > > index 04b0f96..50f20ba 100644
> > > --- a/meta/conf/machine/include/tune-x86_64.inc
> > > +++ b/meta/conf/machine/include/tune-x86_64.inc
> > > @@ -1,3 +1,3 @@
> > >  require conf/machine/include/ia32/arch-ia32.inc
> > >
> > > -DEFAULTTUNE = "x86-64"
> > > +DEFAULTTUNE ?= "x86-64"
> >
> > This one is also not mentioned in the checkin message and looks a bit
> > more dubious to me.  Why is this required?
> >
> It was required at one point when multilist support was quiet unstable.
> The reason it is done because the arch-ia32.inc file is included for
> both x86, tune-core, & x86-64 and setting this hard assignment, was
> breaking x86 or x32 targets. Not sure if it is still needed, I will
> check it.
Just checked, this is needed, when qemux86-64 machine is configured with x32 
abi, when a different default tune is used.
Nitin

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

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

Re: [OE-core] [PATCH] libc-package bbclass: fix binary localedata dependency code

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 3:00 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH] libc-package bbclass: fix binary
> localedata dependency code
> 
> On Wed, 2011-08-03 at 08:19 +0200, Koen Kooi wrote:
> > Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
> >
> > > It does look a bit weird.  That code was introduced in 561d8754,
> > > ostensibly as a merger of the eglibc and glibc equivalents.  But,
> the
> > > original code from glibc-package.bbclass did:
> > >
> > >   def output_locale_binary_rdepends(name, pkgname, locale,
> encoding):
> > >   m = re.match("(.*)\.(.*)", name)
> > >   if m:
> > >   glibc_name = "%s.%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> > >   else:
> > >   glibc_name = name
> > >   bb.data.setVar('RDEPENDS_%s' % pkgname,
> legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
> > >
> > > ... i.e. it was using the "." separator both for splitting and
> joining,
> > > which seems reasonable.  But somehow when it showed up in
> > > libc-package.bbclass it had gotten transmogrified so that it split
> on
> > > "_" but joined with "." as you showed below.  That seems bogus to
> me.
> 
> I'm not sure whether your original locale problem is still an issue,
> but
> I am still fairly convinced that the change to the regex in the code
> above was incorrect.  Unless the author of 561d8754 wants to speak up
> in
> its defence soon, I will submit a patch to change it back to using ".".
> 
> p.
> 
Phil,
   Feel free to do the right thing. :) I am out of context here, and need to 
dig this further to understand the situation better. 
Nitin


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

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

Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 3:10 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On Thu, 2011-08-04 at 15:04 -0700, Kamble, Nitin A wrote:
> >
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> > > Phil Blundell
> > > Sent: Thursday, August 04, 2011 2:51 PM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> > > support for glibc recipes
> > >
> > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> > > > From: Nitin A Kamble 
> > > >
> > > > Signed-off-by: Nitin A Kamble 
> > >
> > > This commit message is very terse.  Why is this change necessary?
> >
> > Because meta-x32 layer has glibc, which needs these support files. I
> will update the commit message in the tree.
> 
> Can't the tclibc-glibc file go in meta-x32 as well, then?
> 
It can go in the meta-x32 layer, but I think better place for this support file 
is in the meta layer. It would help avoid duplication of the code in multiple 
layers.

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

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

Re: [OE-core] [PATCH 07/10] siteinfo.bbclass: add entries for new x86_64 ABI targets

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Thursday, August 04, 2011 3:52 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 07/10] siteinfo.bbclass: add entries for
> new x86_64 ABI targets
> 
> On Thu, Aug 4, 2011 at 8:01 AM,   wrote:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/classes/siteinfo.bbclass |   14 +-
> >  1 files changed, 13 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta/classes/siteinfo.bbclass
> b/meta/classes/siteinfo.bbclass
> > index 9dacd58..daa7946 100644
> > --- a/meta/classes/siteinfo.bbclass
> > +++ b/meta/classes/siteinfo.bbclass
> > @@ -42,12 +42,15 @@ def siteinfo_data(d):
> >         "sh4": "endian-little bit-32 sh-common",
> >         "sparc": "endian-big bit-32",
> >         "viac3": "endian-little bit-32 ix86-common",
> > -        "x86_64": "endian-little bit-64",
> > +        "x86_64": "endian-little", # bitinfo specified in targetinfo
> >     }
> >     osinfo = {
> >         "darwin": "common-darwin",
> >         "darwin9": "common-darwin",
> >         "linux": "common-linux common-glibc",
> > +        "linux-gnu32": "common-linux common-glibc",
> > +        "linux-gnux32": "common-linux common-glibc",
> > +        "linux-gnu64": "common-linux common-glibc",
> >         "linux-gnueabi": "common-linux common-glibc",
> >         "linux-gnuspe": "common-linux common-glibc",
> >         "linux-uclibc": "common-linux common-uclibc",
> > @@ -68,6 +71,15 @@ def siteinfo_data(d):
> >         "powerpc-linux-uclibcspe": "powerpc-linux powerpc32-linux
> powerpc-linux-uclibc",
> >         "powerpc64-linux-gnuspe": "powerpc-linux powerpc64-linux",
> >         "powerpc64-linux": "powerpc-linux",
> > +        "x86_64-cygwin": "bit-64",
> > +        "x86_64-darvin": "bit-64",
> > +        "x86_64-darvin9": "bit-64",
> 
> You still haven't fixed this typo. It's darWin not darVin.
Got it. Thanks for catching this again :)
Nitin

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

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

Re: [OE-core] [PATCH 10/10] local.conf.sample: make BBMASK assignment weak

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Thursday, August 04, 2011 3:53 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 10/10] local.conf.sample: make BBMASK
> assignment weak
> 
> On Thu, Aug 4, 2011 at 8:01 AM,   wrote:
> > From: Nitin A Kamble 
> >
> > So that it can be overridden by layers if needed.
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta-yocto/conf/local.conf.sample |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta-yocto/conf/local.conf.sample b/meta-
> yocto/conf/local.conf.sample
> > index 3e71b0a..4acec37 100644
> > --- a/meta-yocto/conf/local.conf.sample
> > +++ b/meta-yocto/conf/local.conf.sample
> > @@ -39,7 +39,7 @@ DISTRO ?= "poky"
> >
> >  # BBMASK is a regular expression that can be used to tell BitBake to
> ignore
> >  # certain recipes.
> > -BBMASK = ""
> > +BBMASK ?= ""
> >
> >  # EXTRA_IMAGE_FEATURES allows extra packages to be added to the
> generated images
> >  # (Some of these are automatically added to certain image types)
> 
> In oe.dev we just dropped this from local.conf iirc since a real
> assignmnet was overriding a useful setting we provided.  IMHO, we
> should do the same here (or at least comment it out).

I agree. We should comment it out.
> 
> --
> Tom
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Thursday, August 04, 2011 3:50 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On Thu, Aug 4, 2011 at 3:47 PM, Kamble, Nitin A
>  wrote:
> >
> >
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> >> Phil Blundell
> >> Sent: Thursday, August 04, 2011 3:10 PM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> >> support for glibc recipes
> >>
> >> On Thu, 2011-08-04 at 15:04 -0700, Kamble, Nitin A wrote:
> >> >
> >> > > -Original Message-
> >> > > From: openembedded-core-boun...@lists.openembedded.org
> >> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On
> Behalf
> >> Of
> >> > > Phil Blundell
> >> > > Sent: Thursday, August 04, 2011 2:51 PM
> >> > > To: Patches and discussions about the oe-core layer
> >> > > Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the
> needed
> >> > > support for glibc recipes
> >> > >
> >> > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com
> wrote:
> >> > > > From: Nitin A Kamble 
> >> > > >
> >> > > > Signed-off-by: Nitin A Kamble 
> >> > >
> >> > > This commit message is very terse.  Why is this change
> necessary?
> >> >
> >> > Because meta-x32 layer has glibc, which needs these support files.
> I
> >> will update the commit message in the tree.
> >>
> >> Can't the tclibc-glibc file go in meta-x32 as well, then?
> >>
> > It can go in the meta-x32 layer, but I think better place for this
> support file is in the meta layer. It would help avoid duplication of
> the code in multiple layers.
> 
> Part of the answer here is that obsolete / etc things don't belong in
> the core, but in other layers that need them.  My read on things is
> that we've removed glibc in favor of eglibc...

With high demand I will move the glibc file in the meta-x32 layer. I was trying 
to do what felt right at 1st, but I wasn't aware that eglibc is favored so much 
over glibc.
> 
> --
> Tom
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Thursday, August 04, 2011 3:49 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On Thu, Aug 4, 2011 at 3:04 PM, Kamble, Nitin A
>  wrote:
> >
> >
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> >> Phil Blundell
> >> Sent: Thursday, August 04, 2011 2:51 PM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> >> support for glibc recipes
> >>
> >> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> >> > From: Nitin A Kamble 
> >> >
> >> > Signed-off-by: Nitin A Kamble 
> >>
> >> This commit message is very terse.  Why is this change necessary?
> >
> > Because meta-x32 layer has glibc, which needs these support files. I
> will update the commit message in the tree.
> 
> Can x32 not use eglibc?
Not yet, x32 work is done on the glibc tip, and eglibc is not there to pick up 
the work.

Nitin

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

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

Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Thursday, August 04, 2011 4:19 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On 08/04/2011 08:01 AM, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble
> >
> > Signed-off-by: Nitin A Kamble
> > ---
> >   meta/conf/distro/include/tclibc-glibc.inc   |   32
> +++
> >   meta/conf/distro/include/tcmode-default.inc |5 
> >   2 files changed, 37 insertions(+), 0 deletions(-)
> >   create mode 100644 meta/conf/distro/include/tclibc-glibc.inc
> >
> > diff --git a/meta/conf/distro/include/tclibc-glibc.inc
> b/meta/conf/distro/include/tclibc-glibc.inc
> > new file mode 100644
> > index 000..823195c
> > --- /dev/null
> > +++ b/meta/conf/distro/include/tclibc-glibc.inc
> > @@ -0,0 +1,32 @@
> > +#
> > +# glibc specific configuration
> > +#
> > +
> > +LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION', True) or
> '') != '']}"
> 
> why is this specific to glibc and not eglibc ?

I think that is for multilib. I did not do any changes to the tclibc-glibc.inc 
files. I just got back the last version before deletion.

> since glibc is deleted from metadata this file should go away too
> if its for external toolchains then they could use tclibc-eglibc.inc
> or tclibc-uclibc.inc as needed.


> 
> I am in favour of generally using linux-gnu extention for eglibc/glibc
> based systems.
> 
> > +
> > +# Add glibc to the overrides.
> > +OVERRIDES =. "libc-glibc:"
> > +
> > +PREFERRED_PROVIDER_virtual/libiconv ?= "glibc"
> > +PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= "glibc-nativesdk"
> > +PREFERRED_PROVIDER_virtual/libintl ?= "glibc"
> > +PREFERRED_PROVIDER_virtual/libc ?= "glibc"
> > +PREFERRED_PROVIDER_virtual/libc-nativesdk ?= "glibc-nativesdk"
> > +PREFERRED_PROVIDER_virtual/libc-locale ?= "glibc-locale"
> > +
> > +CXXFLAGS += "-fvisibility-inlines-hidden"
> > +
> > +LIBC_DEPENDENCIES = "\
> > +libsegfault \
> > +glibc \
> > +glibc-dbg \
> > +glibc-dev \
> > +glibc-utils \
> > +glibc-thread-db \
> > +glibc-localedata-i18n \
> > +glibc-gconv-ibm850 \
> > +glibc-gconv-cp1252 \
> > +glibc-gconv-iso8859-1 \
> > +glibc-gconv-iso8859-15 \
> > +locale-base-en-gb \
> > +"
> > diff --git a/meta/conf/distro/include/tcmode-default.inc
> b/meta/conf/distro/include/tcmode-default.inc
> > index 0d0af38..5f66c9e 100644
> > --- a/meta/conf/distro/include/tcmode-default.inc
> > +++ b/meta/conf/distro/include/tcmode-default.inc
> > @@ -48,6 +48,11 @@ PREFERRED_VERSION_binutils-crosssdk ?=
> "${BINUVERSION}"
> >   PREFERRED_VERSION_binutils-cross-canadian ?= "${BINUVERSION}"
> >   PREFERRED_VERSION_linux-libc-headers ?= "${LINUXLIBCVERSION}"
> >   PREFERRED_VERSION_linux-libc-headers-nativesdk ?=
> "${LINUXLIBCVERSION}"
> > +PREFERRED_VERSION_glibc ?= "${GLIBCVERSION}"
> > +PREFERRED_VERSION_glibc-locale ?= "${GLIBCVERSION}"
> > +PREFERRED_VERSION_glibc-nativesdk ?= "${GLIBCVERSION}"
> > +PREFERRED_VERSION_glibc-initial ?= "${GLIBCVERSION}"
> > +PREFERRED_VERSION_glibc-initial-nativesdk ?= "${GLIBCVERSION}"
> >   PREFERRED_VERSION_eglibc   ?= "${EGLIBCVERSION}"
> >   PREFERRED_VERSION_eglibc-locale?= "${EGLIBCVERSION}"
> >   PREFERRED_VERSION_eglibc-nativesdk ?= "${EGLIBCVERSION}"
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Friday, August 05, 2011 12:51 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> tune parameters
> 
> On Thu, 2011-08-04 at 15:18 -0700, Kamble, Nitin A wrote:
> >
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> > > Phil Blundell
> > > Sent: Thursday, August 04, 2011 2:57 PM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32
> abi
> > > tune parameters
> > >
> > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> > > >  # ELF32 ABI
> > > >  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> > > > -TUNECONFLICTS[m32] = "m64"
> > > > +TUNECONFLICTS[m32] = "m64 mx32"
> > > >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> > > "${X86ARCH32}", "" ,d)}"
> > > > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "32",
> > > "" ,d)}"
> > > >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-
> m32",
> > > "", d)}"
> > >
> > > This is going to cause TARGET_OS to change for everyone using the
> i586
> > > ABI, right?  That doesn't seem like it is either necessary or
> > > desirable,
> > > and it isn't mentioned in the checkin comment either.
> >
> > Correct, this will change the TARGET_OS from linux_gnu to
> linux_gnu32. And it is also applicable for x86-64 machine set with x86
> tune. This change is be needed if multiple tunes are built from the
> same build directory. If such situation is not important then the
> ABIEXTENSION part can be dropped.
> 
> Well, if you build i686 and x32 in the same tree they will already be
> disambiguated through TARGET_ARCH.  Likewise i686 and x86-64 already
> works for the same reason.  So, the only possible conflict is between
> x86-64 and x32, and setting ABIEXTENSION for x32 (only) would be
> sufficient to avoid that.
> 
Now for TARGET_ARCH=x86_64 there are multiple targets, one is 64bit, another 
is x32 and yet another is 32. This is new addition due to multilib changes. 
To distinguish the these different ABI target, TARGET_OS is appended with 
the ABIEXTENSION.

> Though, I do wonder whether x32 ought to just have its own TARGET_ARCH
> value rather than trying to disambiguate it through TARGET_OS hackery.


Changing TARGET_ARCH is not correct way to handle it. Because HW/ARCH is 
not different, the difference is in the ABI of the OS. And also changing 
TARGET_ARCH would bring lot of other changes in recipes and classes in the 
Tree.

Thanks,
Nitin

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

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

Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Friday, August 05, 2011 12:52 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix
> KERNEL_LD & KERNEL_AR vars
> 
> On Thu, 2011-08-04 at 15:03 -0700, Kamble, Nitin A wrote:
> >
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> > > Phil Blundell
> > > Sent: Thursday, August 04, 2011 2:50 PM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass:
> fix
> > > KERNEL_LD & KERNEL_AR vars
> > >
> > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> > > > From: Nitin A Kamble 
> > > >
> > > > KERNEL_LD was using ${LD} in it's definition, which is not
> correct
> > > for
> > > > different ABIs such as x32 or i386 on x86_64 machine.
> > > >
> > > > Same with KERNEL_AR var.
> > >
> > > Why is ar an issue?  That doesn't have any unusual args, does it?
> > >
> > > p.
> >
> > No special args for ar, but The change makes definition of KERNEL_AR
> consistent with other definitions like KERNEL_CC & KERNEL_LD.
> 
> Okay, fair enough.  Please say that in the checkin message, though.
> The
> existing text makes it sound as though KERNEL_AR was actually broken
> before.
> 
Point noted, Changed the commit message.

Nitin

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

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

Re: [OE-core] [PATCH 08/10] insane.bbclass: add entries for linux-gnu

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Friday, August 05, 2011 9:07 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 08/10] insane.bbclass: add entries for
> linux-gnu
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > for x86_64 multiple ABIs now have these new names for the TARGET_OS.
> > Add entries for:
> >  linux-gnu32, linux-gnux32, linux-gnu64
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/classes/insane.bbclass |9 +
> >  1 files changed, 9 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta/classes/insane.bbclass
> b/meta/classes/insane.bbclass
> > index 5fb0d98..15e7fc7 100644
> > --- a/meta/classes/insane.bbclass
> > +++ b/meta/classes/insane.bbclass
> > @@ -90,6 +90,15 @@ def package_qa_get_machine_dict():
> >  "microblaze":   (47787,  0,0,
> False, 32),
> >  "microblazeel": (47787,  0,0,
> True,  32),
> >},
> > +"linux-gnu32" :   {
> > +"x86_64": (62, 0,0,
> True,  32),
> > +  },
> 
> This one doesn't make sense to me. linux-gnu32 would be i586 (arch=3)
> and not arch=62?
> 
> > +"linux-gnux32" :   {
> > +"x86_64": (62, 0,0,
> True,  32),
> > +  },
> 
> This one is fine.
> 
> > +"linux-gnu64" :   {
> > +"x86_64": (62, 0,0,
> True,  64),
> > +  },
> > }
> 
> I'm not sure we need this either...

If the ABIEXTENTION is taken out for m32 & m64 tunes, then these are not 
needed. So I will take them out.
Thanks,
Nitin

> 
> Cheers,
> 
> Richard
> 
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Friday, August 05, 2011 9:04 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> tune parameters
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/conf/machine/include/ia32/arch-ia32.inc |   23
> ---
> >  meta/conf/machine/include/tune-core2.inc |4 
> >  meta/conf/machine/include/tune-x86_64.inc|2 +-
> >  3 files changed, 25 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
> b/meta/conf/machine/include/ia32/arch-ia32.inc
> > index 2709440..fb527da 100644
> > --- a/meta/conf/machine/include/ia32/arch-ia32.inc
> > +++ b/meta/conf/machine/include/ia32/arch-ia32.inc
> > @@ -6,17 +6,29 @@ DEFAULTTUNE ?= "x86"
> >  TARGET_FPU ?= ""
> >  X86ARCH32 ?= "i586"
> >  X86ARCH64 ?= "x86_64"
> > +X86ARCHX32 ?= "x86_64"
> >
> >  # ELF32 ABI
> >  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> > -TUNECONFLICTS[m32] = "m64"
> > +TUNECONFLICTS[m32] = "m64 mx32"
> >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "${X86ARCH32}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32",
> "" ,d)}"
> 
> Please drop the above line. There is no need to change that.
> 
> >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
> "", d)}"
> >
> > +# x32 ABI
> > +TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI"
> > +TUNECONFLICTS[mx32] = "m64 m32"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
> "${X86ARCHX32}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
> "x32", "" ,d)}"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
> mx32", "", d)}"
> > +TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m
> elf32_x86_64", "", d)}"
> > +TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
> x32", "", d)}"
> > +
> 
> These are fine.
> 
> >  # ELF64 ABI
> >  TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> > -TUNECONFLICT[m64] = "m32"
> > +TUNECONFLICT[m64] = "m32 mx32"
> >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> "${X86ARCH64}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64",
> "" ,d)}"
> 
> Again, please drop the above line.
> 
> >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64",
> "", d)}"
> >
> >  TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86",
> "x86_64", d)}"
> > @@ -30,4 +42,9 @@ PACKAGE_EXTRA_ARCHS_tune-x86 = "x86"
> >  AVAILTUNES += "x86-64"
> >  TUNE_FEATURES_tune-x86-64 ?= "m64"
> >  BASE_LIB_tune-x86-64 ?= "lib64"
> > -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
> > +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"
> 
> That is likely wrong, please drop this piece.
> 
> > +
> > +AVAILTUNES += "x86-64-x32"
> > +TUNE_FEATURES_tune-x86-64-x32 ?= "mx32"
> > +BASE_LIB_tune-x86-64-x32 ?= "lib"
> > +PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86-64-x32"
> 
> And this is wrong too.
> 
> You really want:
> 
> TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32",
> "", d)}"
> PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86_64-x32"
> 
> > diff --git a/meta/conf/machine/include/tune-core2.inc
> b/meta/conf/machine/include/tune-core2.inc
> > index 25c2226..8a4de3e 100644
> > --- a/meta/conf/machine/include/tune-core2.inc
> > +++ b/meta/conf/machine/include/tune-core2.inc
> > @@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?=
> "${TUNE_FEATURES_tune-x86-64} core2"
> >  BASE_LIB_tune-core2-64 ?= "lib64"
> >  PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-
> 64} core2-64"
> >
> > +AVAILTUNES += "core2-x32"
> > +TUNE_FEATURES_tune-core2-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32}
> core2"
> > +BASE_LIB_tune-core2-x32 ?= "lib"
> > +PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-
> x86-64-x32} core2-x32"
> 
> PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-
> 64-x32} core2-64-x32"
> 
> Cheers,
> 
> Richard
> 
> 

Richard,
  Changed the commits according to the comments, please pull/cherry-pick again.

Thanks,
Nitin



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

Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Saul Wold
> Sent: Friday, August 05, 2011 2:24 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> tune parameters
> 
> On 08/05/2011 11:07 AM, Kamble, Nitin A wrote:
> >
> >
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> >> Richard Purdie
> >> Sent: Friday, August 05, 2011 9:04 AM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> >> tune parameters
> >>
> >> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kam...@intel.com wrote:
> >>> From: Nitin A Kamble
> >>>
> >>> Signed-off-by: Nitin A Kamble
> >>> ---
> >>>   meta/conf/machine/include/ia32/arch-ia32.inc |   23
> >> ---
> >>>   meta/conf/machine/include/tune-core2.inc |4 
> >>>   meta/conf/machine/include/tune-x86_64.inc|2 +-
> >>>   3 files changed, 25 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
> >> b/meta/conf/machine/include/ia32/arch-ia32.inc
> >>> index 2709440..fb527da 100644
> >>> --- a/meta/conf/machine/include/ia32/arch-ia32.inc
> >>> +++ b/meta/conf/machine/include/ia32/arch-ia32.inc
> >>> @@ -6,17 +6,29 @@ DEFAULTTUNE ?= "x86"
> >>>   TARGET_FPU ?= ""
> >>>   X86ARCH32 ?= "i586"
> >>>   X86ARCH64 ?= "x86_64"
> >>> +X86ARCHX32 ?= "x86_64"
> >>>
> >>>   # ELF32 ABI
> >>>   TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> >>> -TUNECONFLICTS[m32] = "m64"
> >>> +TUNECONFLICTS[m32] = "m64 mx32"
> >>>   TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> >> "${X86ARCH32}", "" ,d)}"
> >>> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "32",
> >> "" ,d)}"
> >>
> >> Please drop the above line. There is no need to change that.
> >>
> >>>   TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-
> m32",
> >> "", d)}"
> >>>
> >>> +# x32 ABI
> >>> +TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI"
> >>> +TUNECONFLICTS[mx32] = "m64 m32"
> >>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
> >> "${X86ARCHX32}", "" ,d)}"
> >>> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
> >> "x32", "" ,d)}"
> >>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
> >> mx32", "", d)}"
> >>> +TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m
> >> elf32_x86_64", "", d)}"
> >>> +TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
> >> x32", "", d)}"
> >>> +
> >>
> >> These are fine.
> >>
> >>>   # ELF64 ABI
> >>>   TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> >>> -TUNECONFLICT[m64] = "m32"
> >>> +TUNECONFLICT[m64] = "m32 mx32"
> >>>   TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> >> "${X86ARCH64}", "" ,d)}"
> >>> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> "64",
> >> "" ,d)}"
> >>
> >> Again, please drop the above line.
> >>
> >>>   TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-
> m64",
> >> "", d)}"
> >>>
> >>>   TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "x86",
> >> &qu

Re: [OE-core] how to pass or set specific gcc flags?

[Kamble, Nitin A]

Kumar,
Look at the meta/conf/machine/include/ia32/arch-ia32.inc where we have done 
special flags passing to gcc & other tools.

Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Kumar Gala
> Sent: Sunday, August 07, 2011 10:09 AM
> To: Patches and discussions about the oe-core layer
> Subject: [OE-core] how to pass or set specific gcc flags?
> 
> We'd like to pass:
> 
> --enable-targets=all
> 
> on ppc when we target a 64-bit platform but happen to build a 32-bit
> toolchain & rootfs, its useful to still have 64-bit support in the
> compiler to build a 64-bit kernel if desired in this scenario.  Also,
> this seems useful for the multilib situation.
> 
> Wondering what the best way of doing this.  Adding something into the
> tune-ppcFOOBAR file but not sure how to do that so it gets picked up by
> the right toolchain pass.  And what do we even override?  I suggested
> adding a GCC_EXTRA_OECONF.
> 
> - k
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH] libc-package bbclass: fix binary localedata dependency code

[Kamble, Nitin A]

Hi Koen,
  Sorry for replying late, I am on vacation now. I looked at my commit 
561d875404ef1783f94f37314b6e756766db8411, and from it I see that both eglibc & 
glibc package.bbclass has same lines 
-   if m:
-   eglibc_name = "%s.%s" % (m.group(1), 
m.group(2).lower().replace("-",""))
-   else:
-   eglibc_name = name
So I am not sure that this is the correct fix. I will look into it further and 
reply later.
Thanks,
Nitin

> -Original Message-
> From: Koen Kooi [mailto:k...@dominion.thruhere.net]
> Sent: Tuesday, August 09, 2011 11:14 PM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCH] libc-package bbclass: fix binary
> localedata dependency code
> 
> Nitin, any insights on this?
> 
> Op 2 aug. 2011, om 17:01 heeft Phil Blundell het volgende geschreven:
> 
> > It does look a bit weird.  That code was introduced in 561d8754,
> > ostensibly as a merger of the eglibc and glibc equivalents.  But, the
> > original code from glibc-package.bbclass did:
> >
> >   def output_locale_binary_rdepends(name, pkgname, locale,
> encoding):
> >   m = re.match("(.*)\.(.*)", name)
> >   if m:
> >   glibc_name = "%s.%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> >   else:
> >   glibc_name = name
> >   bb.data.setVar('RDEPENDS_%s' % pkgname,
> legitimize_package_name('glibc-binary-localedata-%s' % glibc_name), d)
> >
> > ... i.e. it was using the "." separator both for splitting and
> joining,
> > which seems reasonable.  But somehow when it showed up in
> > libc-package.bbclass it had gotten transmogrified so that it split on
> > "_" but joined with "." as you showed below.  That seems bogus to me.
> >
> > p.
> >
> > On Tue, 2011-08-02 at 16:55 +0200, Koen Kooi wrote:
> >> The bug I was seeing was caused by something else, but I'd still
> like feedback on this patch to find out why the dot vs dash difference
> exists
> >>
> >> Op 2 aug. 2011, om 16:47 heeft Koen Kooi het volgende geschreven:
> >>
> >>> When using binary locales rootfs generation fails with:
> >>>
> >>> | Unknown package 'locale-base-en-us'.
> >>> | Collected errors:
> >>> |  * opkg_install_cmd: Cannot install package locale-base-en-us.
> >>>
> >>> This is due to:
> >>>
> >>> $ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk |
> grep Depends
> >>> Depends: eglibc-binary-localedata-en.us
> >>>
> >>> Note the '.' seperator
> >>>
> >>> $ ls ipk/armv7a/ | grep binary-localedata-en | grep us
> >>> eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk
> >>>
> >>> Note the '-' seperator vs the '.' in the locale-base packages.
> >>>
> >>> Signed-off-by: Koen Kooi 
> >>> ---
> >>> meta/classes/libc-package.bbclass |2 +-
> >>> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-
> package.bbclass
> >>> index de57230..67d08c0 100644
> >>> --- a/meta/classes/libc-package.bbclass
> >>> +++ b/meta/classes/libc-package.bbclass
> >>> @@ -243,7 +243,7 @@ python package_do_split_gconvs () {
> >>>   def output_locale_binary_rdepends(name, pkgname, locale,
> encoding):
> >>>   m = re.match("(.*)_(.*)", name)
> >>>   if m:
> >>> - libc_name = "%s.%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> >>> + libc_name = "%s-%s" % (m.group(1),
> m.group(2).lower().replace("-",""))
> >>>   else:
> >>>   libc_name = name
> >>>   bb.data.setVar('RDEPENDS_%s' % pkgname,
> legitimize_package_name('%s-binary-localedata-%s' \
> >>> --
> >>> 1.6.6.1
> >>>
> >>
> >>
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> core
> >
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


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

Re: [OE-core] [PATCH 01/11] gst-fluendo.inc: remove unneccessary hack

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Wednesday, December 07, 2011 11:37 PM
> To: Patches and discussions about the oe-core layer
> Cc: hjl.to...@gmail.com
> Subject: Re: [OE-core] [PATCH 01/11] gst-fluendo.inc: remove
> unneccessary hack
> 
> On Wed, Dec 7, 2011 at 9:48 PM,   wrote:
> > From: Nitin A Kamble 
> >
> > This fixes bug: [YOCTO #1403]
> >
> > the custom definition of CC was causing build isuses with x32
> toolchain.
> > And also I found out that the hack is not neccessary anymore. the
> > affected gst-fluendo-mpegdemux recipe builds fine without the CC
> hack.
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/recipes-multimedia/gstreamer/gst-fluendo.inc |    4 
> >  1 files changed, 0 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
> b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
> > index 203bdba..8b24cf7 100644
> > --- a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
> > +++ b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
> > @@ -12,7 +12,3 @@ FILES_${PN}-dbg += "${libdir}/gstreamer-
> 0.10/.debug"
> >  FILES_${PN}-dev += "${libdir}/gstreamer-0.10/*.la
> ${libdir}/gstreamer-0.10/*.a"
> >
> >  EXTRA_OECONF = "--disable-debug --disable-valgrind"
> > -
> > -# Hack to get STAGING_LIBDIR into the linker path when building
> > -CC = "${CCACHE} ${HOST_PREFIX}gcc -L${STAGING_LIBDIR}"
> > -
> 
> this needs a PR bump

I purposely did not bump PR here, because it does not change output of the 
recipe.

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

Re: [OE-core] [PATCH 02/11] mdadm: Make custom CC definition conditional

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Wednesday, December 07, 2011 11:20 PM
> To: Patches and discussions about the oe-core layer
> Cc: hjl.to...@gmail.com
> Subject: Re: [OE-core] [PATCH 02/11] mdadm: Make custom CC definition
> conditional
> 
> On Wed, Dec 7, 2011 at 9:48 PM,   wrote:
> > +
> > ++ifndef CC
> > + CC = $(CROSS_COMPILE)gcc
> > ++endif
> > ++
> 
> may be you could do
> 
> CC ?= $(CROSS_COMPILE)gcc
> here instead

Yes, This way also works the same, I changed the commit accordingly.

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

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

Re: [OE-core] [PATCH 05/11] findutils: Fix compilation for x32 toolchain

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Thursday, December 08, 2011 1:08 AM
> To: Patches and discussions about the oe-core layer
> Cc: hjl.to...@gmail.com
> Subject: Re: [OE-core] [PATCH 05/11] findutils: Fix compilation for x32
> toolchain
> 
> On Wed, 2011-12-07 at 23:14 -0800, Khem Raj wrote:
> > On Wed, Dec 7, 2011 at 9:48 PM,   wrote:
> > > From: Nitin A Kamble 
> > >
> > > Work around gnulib time_t assumption in findutils for x32
> >
> > if its a workaround can it be applied only to x32 with help of
> overrides please
> 
> Its not a workaround, the patch looks like a generic reasonable fix to
> correct assumptions made by the program that aren't true?


Even though x32 caught the issue, the issue is not x32 specific. And also 
other arches are building fine with the change. So I think it is better 
to keep this patch in oecore.

Nitin

> 
> Cheers,
> 
> Richard
> 
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 02/11] mdadm: Make custom CC definition conditional

[Kamble, Nitin A]

I updated the mdadm commit on contrib branch. So the pull of nitin/x32 branch 
will get the right commit.

Thanks,
Nitin

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Kamble, Nitin A
> Sent: Thursday, December 08, 2011 10:36 AM
> To: Patches and discussions about the oe-core layer
> Cc: hjl.to...@gmail.com
> Subject: Re: [OE-core] [PATCH 02/11] mdadm: Make custom CC definition
> conditional
> 
> 
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> > Khem Raj
> > Sent: Wednesday, December 07, 2011 11:20 PM
> > To: Patches and discussions about the oe-core layer
> > Cc: hjl.to...@gmail.com
> > Subject: Re: [OE-core] [PATCH 02/11] mdadm: Make custom CC definition
> > conditional
> >
> > On Wed, Dec 7, 2011 at 9:48 PM,   wrote:
> > > +
> > > ++ifndef CC
> > > + CC = $(CROSS_COMPILE)gcc
> > > ++endif
> > > ++
> >
> > may be you could do
> >
> > CC ?= $(CROSS_COMPILE)gcc
> > here instead
> 
> Yes, This way also works the same, I changed the commit accordingly.
> 
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 05/11] findutils: Fix compilation for x32 toolchain

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Thursday, December 08, 2011 12:45 PM
> To: Patches and discussions about the oe-core layer
> Cc: hjl.to...@gmail.com
> Subject: Re: [OE-core] [PATCH 05/11] findutils: Fix compilation for x32
> toolchain
> 
> On Thu, Dec 8, 2011 at 10:37 AM, Kamble, Nitin A
>  wrote:
> >
> >
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> >> Richard Purdie
> >> Sent: Thursday, December 08, 2011 1:08 AM
> >> To: Patches and discussions about the oe-core layer
> >> Cc: hjl.to...@gmail.com
> >> Subject: Re: [OE-core] [PATCH 05/11] findutils: Fix compilation for
> x32
> >> toolchain
> >>
> >> On Wed, 2011-12-07 at 23:14 -0800, Khem Raj wrote:
> >> > On Wed, Dec 7, 2011 at 9:48 PM,   wrote:
> >> > > From: Nitin A Kamble 
> >> > >
> >> > > Work around gnulib time_t assumption in findutils for x32
> >> >
> >> > if its a workaround can it be applied only to x32 with help of
> >> overrides please
> >>
> >> Its not a workaround, the patch looks like a generic reasonable fix
> to
> >> correct assumptions made by the program that aren't true?
> >
> >
> > Even though x32 caught the issue, the issue is not x32 specific. And
> also
> > other arches are building fine with the change. So I think it is
> better
> > to keep this patch in oecore.
> 
> OK then change the commit message its confusing.

Ok, I changed the commit message in the contrib. branch nitin/x32.
Nitin

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

Re: [OE-core] [PATCH 2/3] dosfstools: update native to 2.11

[Kamble, Nitin A]

I verified it is building fine for all arches.

Nitin

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Otavio Salvador
> Sent: Thursday, December 08, 2011 7:41 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 2/3] dosfstools: update native to 2.11
>
> This unify recipes for target and native builds and also drops the the
> already merged patches.
>
> Signed-off-by: Otavio Salvador 
> ---
>  .../dosfstools/dosfstools-native_2.10.bb   |   19 -
>  .../dosfstools/dosfstools/2.6.20-syscall.patch |   72 
> ---
>  .../dosfstools/dosfstools-2.10-kernel-2.6.patch|   74 
> 
>  .../dosfstools/dosfstools/mkdosfs-bootcode.patch   |   68 
> --
>  .../dosfstools/dosfstools/mkdosfs-dir.patch|   62 
> -
>  .../recipes-devtools/dosfstools/dosfstools_2.10.bb |   24 --
>  .../recipes-devtools/dosfstools/dosfstools_2.11.bb |   11 ++-
>  7 files changed, 69 insertions(+), 261 deletions(-)
>  delete mode 100644 meta/recipes-devtools/dosfstools/dosfstools-
> native_2.10.bb
>  delete mode 100644 meta/recipes-devtools/dosfstools/dosfstools/2.6.20-
> syscall.patch
>  delete mode 100644 meta/recipes-
> devtools/dosfstools/dosfstools/dosfstools-2.10-kernel-2.6.patch
>  delete mode 100644 meta/recipes-devtools/dosfstools/dosfstools_2.10.bb
>
> diff --git a/meta/recipes-devtools/dosfstools/dosfstools-native_2.10.bb
> b/meta/recipes-devtools/dosfstools/dosfstools-native_2.10.bb
> deleted file mode 100644
> index 91ff11f..000
> --- a/meta/recipes-devtools/dosfstools/dosfstools-native_2.10.bb
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -# dosfstools-native OE build file
> -# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights
> Reserved
> -# Released under the MIT license (see packages/COPYING)
> -
> -require dosfstools_${PV}.bb
> -
> -PR="r5"
> -
> -SRC_URI = "ftp://ftp.uni-
> erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-${PV}.src.tar.gz \
> - file://mkdosfs-bootcode.patch \
> - file://mkdosfs-dir.patch \
> - file://alignment_hack.patch \
> - file://dosfstools-2.10-kernel-2.6.patch \
> - file://msdos_fat12_undefined.patch \
> - file://dosfstools-msdos_fs-types.patch \
> - file://include-linux-types.patch \
> - file://2.6.20-syscall.patch"
> -
> -inherit native
> diff --git a/meta/recipes-devtools/dosfstools/dosfstools/2.6.20-
> syscall.patch b/meta/recipes-devtools/dosfstools/dosfstools/2.6.20-
> syscall.patch
> deleted file mode 100644
> index 4460f06..000
> --- a/meta/recipes-devtools/dosfstools/dosfstools/2.6.20-syscall.patch
> +++ /dev/null
> @@ -1,72 +0,0 @@
> -Only use the system's llseek().
> -
> -Upstream-Status: Inappropriate [licensing]
> -We're tracking an old release of dosfstools due to licensing issues.
> -
> -Signed-off-by: Scott Garman 
> -
> -Index: dosfstools-2.10/dosfsck/io.c
> -===
>  dosfstools-2.10.orig/dosfsck/io.c2007-06-07 16:15:52.0
> +0200
> -+++ dosfstools-2.10/dosfsck/io.c 2007-06-07 16:16:06.0 +0200
> -@@ -42,28 +42,11 @@
> - /* Use the _llseek system call directly, because there (once?) was a
> bug in
> -  * the glibc implementation of it. */
> - #include 
> --#if defined __alpha || defined __ia64__ || defined __s390x__ ||
> defined __x86_64__ || defined __ppc64__
> - /* On alpha, the syscall is simply lseek, because it's a 64 bit
> system. */
> - static loff_t llseek( int fd, loff_t offset, int whence )
> - {
> - return lseek(fd, offset, whence);
> - }
> --#else
> --# ifndef __NR__llseek
> --# error _llseek system call not present
> --# endif
> --static _syscall5( int, _llseek, uint, fd, ulong, hi, ulong, lo,
> --  loff_t *, res, uint, wh );
> --
> --static loff_t llseek( int fd, loff_t offset, int whence )
> --{
> --loff_t actual;
> --
> --if (_llseek(fd, offset>>32, offset&0x, &actual, whence)
> != 0)
> --return (loff_t)-1;
> --return actual;
> --}
> --#endif
> -
> -
> - void fs_open(char *path,int rw)
> -Index: dosfstools-2.10/mkdosfs/mkdosfs.c
> -===
>  dosfstools-2.10.orig/mkdosfs/mkdosfs.c   2007-06-07
> 16:15:11.0 +0200
> -+++ dosfstools-2.10/mkdosfs/mkdosfs.c2007-06-07 16:15:30.0
> +0200
> -@@ -116,27 +116,11 @@
> - /* Use the _llseek system call directly, because there (once?) was a
> bug in
> -  * the glibc implementation of it. */
> - #include 
> --#if defined __alpha || defined __ia64__ || defined __s390x__ ||
> defined __x86_64__ || defined __ppc64__
> - /* On alpha, the syscall is simply lseek, because it's a 64 bit
> system. */
> - static loff_t llseek( int fd, loff_t offset, int whence )
> - {
> - return lseek(fd, offset, whence);
> - }
> --#else
> --# ifndef __NR__llseek
> 

Re: [OE-core] [CONSOLIDATED PULL 06/15] pulseaudio: fix compilation with x32 toolchain

[Kamble, Nitin A]

> -Original Message-
> From: Paul Menzel [mailto:paulepan...@users.sourceforge.net]
> Sent: Friday, December 09, 2011 10:46 AM
> To: openembedded-core@lists.openembedded.org
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [CONSOLIDATED PULL 06/15] pulseaudio: fix
> compilation with x32 toolchain
> 
> Dear Nitin,
> 
> 
> Am Freitag, den 09.12.2011, 10:23 -0800 schrieb Saul Wold:
> > From: Nitin A Kamble 
> >
> > This commit makes assembly syntax compatible with x32 toolchain to
> > avoid x32 gcc errors.
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../pulseaudio/pulseaudo_fix_for_x32.patch |  225
> 
> >  .../pulseaudio/pulseaudio_1.1.bb   |3 +-
> >  2 files changed, 227 insertions(+), 1 deletions(-)  create mode
> > 100644
> > meta/recipes-
> multimedia/pulseaudio/pulseaudio/pulseaudo_fix_for_x32.pa
> > tch
> >
> > diff --git
> > a/meta/recipes-
> multimedia/pulseaudio/pulseaudio/pulseaudo_fix_for_x32.
> > patch
> > b/meta/recipes-
> multimedia/pulseaudio/pulseaudio/pulseaudo_fix_for_x32.
> > patch
> > new file mode 100644
> > index 000..22fe2e7
> > --- /dev/null
> > +++ b/meta/recipes-
> multimedia/pulseaudio/pulseaudio/pulseaudo_fix_for_
> > +++ x32.patch
> > @@ -0,0 +1,225 @@
> > +UpstreamStatus: Pending
> > +
> > +This patch makes assembly syntax compatible to the x32 toolchain.
> > +
> > +This fixes compilations errors with x32 gcc.
> 
> I would volunteer to send this patch upstream. A more elaborate commit
> message also suited for non-OE users would be helpful. That means what
> does the x32 tool chain do and a paste of the errors you got.

Thank you for volunteering for pushing it upstream.

> 
> > +Signed-Off-By: Nitin A Kamble  2011/12/03
> > +Index: pulseaudio-1.1/src/pulsecore/svolume_mmx.c
> 
> […]
> 
> Please only merge this, when this has been improved.


Improved commit has been pushed to the nitin/x32 contrib branch.

Nitin

> 
> 
> Thanks,
> 
> Paul
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] dosfstools: fix populated image creation with dirs

[Kamble, Nitin A]

> -Original Message-
> From: Darren Hart [mailto:dvh...@linux.intel.com]
> Sent: Thursday, December 15, 2011 12:43 PM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCH 1/1] dosfstools: fix populated image
> creation with dirs
>
>
>
> On 12/14/2011 05:47 PM, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > This fixes bug: [YOCTO #1783]
> >
> > Fix populated image creation. Earlier subdirectories support
> > was broken, and files can only be placed in the root directory.
> > Now directory hirarchy is supported in the image. Also support
> > for long names is extended to directory names.
> >
> > There are some outstanding issues as documented in the patch
> > header, these issues can be worked around by running
> > dosfsck tool after populated image creation. The dosfsck tool
> > is also part of this package.
> >
>
> When using this patch to place the EFI related files into /EFI/BOOT I
> added a "dosfsck -a -l ..." command after the "mkdosfs -d ..." command
> to clean up issues. Unfortunatley, it does not appear capable of fixing
> the . and .. failures:

Darren, Looks like you are on the old commit. I don't see these issues.
Nitin

>
> | dosfsck 2.11, 12 Mar 2005, FAT32, LFN
> | Checking file /ldlinux.sys (LDLINUX.SYS)
> | Checking file /initrd (INITRD)
> | Checking file /syslinux.cfg (SYSLINUX.CFG)
> | Checking file /EFI (EFI)
> | Checking file /grub.cfg (GRUB.CFG)
> | Checking file /bootia32.efi (BOOTIA32.EFI)
> | Checking file /vmlinuz (VMLINUZ)
> | Checking file /rootfs.img (ROOTFS.IMG)
> | /EFI
> |   Directory has non-zero size. Fixing it.
> | /vmlinuz
> |   File size is 4144896 bytes, cluster chain length is > 4145152
> bytes.
> |   Truncating file to 4144896 bytes.
> | Checking file /EFI/BOOT (BOOT)
> | /EFI
> |   "." is missing. Can't fix this yet.
> | /EFI
> |   ".." is missing. Can't fix this yet.
> | /EFI/BOOT
> |   Directory has non-zero size. Fixing it.
> | Checking file /EFI/BOOT/initrd (INITRD)
> | Checking file /EFI/BOOT/grub.cfg (GRUB.CFG)
> | Checking file /EFI/BOOT/bootia32.efi (BOOTIA32.EFI)
> | Checking file /EFI/BOOT/vmlinuz (VMLINUZ)
> | Checking file /EFI/BOOT/rootfs.img (ROOTFS.IMG)
> | /EFI/BOOT
> |   "." is missing. Can't fix this yet.
> | /EFI/BOOT
> |   ".." is missing. Can't fix this yet.
> | /EFI/BOOT/vmlinuz
> |   File size is 4144896 bytes, cluster chain length is > 4145152
> bytes.
> |   Truncating file to 4144896 bytes.
> | Performing changes.
> |
> /build/poky/fri2/tmp/deploy/images/core-image-minimal-fri2-noemgd-
> 20111215191648.hddimg:
> 14 files, 26837/27029 clusters
>
> --
> Darren
>
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../dosfstools/fix_populated_dosfs_creation.patch  |  489
> 
> >  .../recipes-devtools/dosfstools/dosfstools_2.11.bb |5 +-
> >  2 files changed, 492 insertions(+), 2 deletions(-)
> >  create mode 100644 meta/recipes-
> devtools/dosfstools/dosfstools/fix_populated_dosfs_creation.patch
> >
> > diff --git a/meta/recipes-
> devtools/dosfstools/dosfstools/fix_populated_dosfs_creation.patch
> b/meta/recipes-
> devtools/dosfstools/dosfstools/fix_populated_dosfs_creation.patch
> > new file mode 100644
> > index 000..510f12e
> > --- /dev/null
> > +++ b/meta/recipes-
> devtools/dosfstools/dosfstools/fix_populated_dosfs_creation.patch
> > @@ -0,0 +1,489 @@
> > +UpstreamStatus: Inappropriate
> > +
> > +This patch fixes populated dosfs image creation with directory
> > +structures. Earlier it was causing segfault; and only image
> > +population with no subdirectories was working.
> > +
> > +Issues fixed:
> > +1. (dir->count == dir->entries) check was only needed for root
> > +   directory entries. And this check is wrong for non-root
> > +   directories.
> > +2. For each dir entry 2 dir->table entries were needed, one for
> > +   the file/dir and 2nd for long file name support. Earlier long
> > +   name support was added for filenames but the 2nd entry
> > +   allocation, initialization & counting was missed.
> > +3. The memory clearing was missed at the code path after dir->table
> > +   memroy allocation.
> > +4. Add entries for . & .. directories in all non-root directories.
> > +5. The . directory points to the correct entry in fat now.
> > +6. All directoriy entries' size was not zero as required for
> dosfsck,
> > +   Now all directory entries&

Re: [OE-core] [PATCH 3/3] binutils: fix building on distros with matching binutils version

[Kamble, Nitin A]

Martin,
  Thanks for the report.
Nitin
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Wednesday, December 21, 2011 2:41 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 3/3] binutils: fix building on distros
> with matching binutils version
> 
> On Wed, Dec 21, 2011 at 11:27:14AM -0800, nitin.a.kam...@intel.com
> wrote:
> > From: Nitin A Kamble 
> >
> > x86_64 opensuse 11.4 has bintuils version 2.21, and when
> > binutils_2.21 recipe is built for x86_64 target then, the invocation
> > of distro gcc fails with errors like this:
> >
> > /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-
> linux/bin/as:
> > symbol lookup error: /usr/lib64/gcc/x86_64-suse-linux/4.5/..
> > make[2]: *** [sysinfo.o] Error 1
> >
> > The issue rootcaused as incompatible LD_LIBRARY_PATH while running
> the
> > distro gcc.
> >
> > As per Martin Jansa gentoo also sees similar issue with binutils 2.22
> > recipe.
> 
> I can confirm that with similar patch based on your fix for 2.21 in
> poky-contrib/nitin/bugfix I was able to build binutils for qemux86-64
> for first time without manual fix :).
> 
> Cheers,
> 
> > This commit fixes the issue by clearing the LD_LIBRARY_PATH for
> distro
> > gcc (CC_FOR_BUILD)
> >
> > This Fixes bug: [YOCTO #1833]
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../binutils/binutils-cross-canadian_2.22.bb   |2 +-
> >  .../binutils/binutils-crosssdk_2.22.bb |2 +-
> >  meta/recipes-devtools/binutils/binutils.inc|2 +-
> >  meta/recipes-devtools/binutils/binutils_2.22.bb|2 +-
> >  4 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git
> > a/meta/recipes-devtools/binutils/binutils-cross-canadian_2.22.bb
> > b/meta/recipes-devtools/binutils/binutils-cross-canadian_2.22.bb
> > index e91e7dc..a49aded 100644
> > --- a/meta/recipes-devtools/binutils/binutils-cross-canadian_2.22.bb
> > +++ b/meta/recipes-devtools/binutils/binutils-cross-canadian_2.22.bb
> > @@ -1,3 +1,3 @@
> >  require binutils_${PV}.bb
> >  require binutils-cross-canadian.inc
> > -PR = "r1"
> > +PR = "r2"
> > diff --git a/meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb
> > b/meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb
> > index 21289cd..0e8b6e4 100644
> > --- a/meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb
> > +++ b/meta/recipes-devtools/binutils/binutils-crosssdk_2.22.bb
> > @@ -4,7 +4,7 @@ inherit crosssdk
> >
> >  PROVIDES = "virtual/${TARGET_PREFIX}binutils-crosssdk"
> >
> > -PR = "r1"
> > +PR = "r2"
> >
> >  do_configure_prepend () {
> > sed -i 's#/usr/local/lib /lib /usr/lib#${SDKPATHNATIVE}/lib
> > ${SDKPATHNATIVE}/usr/lib /usr/local/lib /lib /usr/lib#'
> > ${S}/ld/configure.tgt diff --git
> > a/meta/recipes-devtools/binutils/binutils.inc
> > b/meta/recipes-devtools/binutils/binutils.inc
> > index 5cb2cc9..30a0416 100644
> > --- a/meta/recipes-devtools/binutils/binutils.inc
> > +++ b/meta/recipes-devtools/binutils/binutils.inc
> > @@ -76,7 +76,7 @@ export RANLIB_FOR_TARGET = "${TARGET_PREFIX}ranlib"
> >  export CC_FOR_HOST = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}"
> >  export CXX_FOR_HOST = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}"
> >
> > -export CC_FOR_BUILD = "${BUILD_CC}"
> > +export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}"
> >  export CPP_FOR_BUILD = "${BUILD_CPP}"
> >  export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}"
> >
> > diff --git a/meta/recipes-devtools/binutils/binutils_2.22.bb
> > b/meta/recipes-devtools/binutils/binutils_2.22.bb
> > index f1e7e12..41a30ee 100644
> > --- a/meta/recipes-devtools/binutils/binutils_2.22.bb
> > +++ b/meta/recipes-devtools/binutils/binutils_2.22.bb
> > @@ -1,6 +1,6 @@
> >  require binutils.inc
> >
> > -PR = "r1"
> > +PR = "r2"
> >
> >  LIC_FILES_CHKSUM="\
> >
> > file://src-release;endline=17;md5=4830a9ef968f3b18dd5e9f2c00db2d35\
> > --
> > 1.7.6.4
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

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

Re: [OE-core] Internal compiler error

[Kamble, Nitin A]

Khem had fixed this in the oecore, I just sent a pull request for that commit 
for edison branch.

Thanks
Nitin


> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Thursday, December 22, 2011 10:33 AM
> To: openembedded-core@lists.openembedded.org
> Cc: Kamble, Nitin A; Khem Raj
> Subject: Internal compiler error
> 
> Hi Nitin/Khem/all,
> 
> We saw a failure on the Yocto Project autobuilder recently which
> appears to be
> the result of an internal compiler error [1] (note this is with the
> edison
> branch of Yocto, so it's somewhat older than what we have in master).
> Some
> searching brought up a Linaro gcc bug that looks remarkably similar
> [2].
> 
> Do you guys know anything about this? Do we need to bring in the fix
> from the
> bug report above?
> 
> Cheers,
> Paul
> 
> [1] http://autobuilder.yoctoproject.org:8010/builders/nightly-
> arm/builds/232/steps/shell_81/logs/stdio
> [2] https://bugs.launchpad.net/gcc-linaro/+bug/723185
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre

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

Re: [OE-core] [PATCH 14/14] automake: upgrade from 1.11.1 to 1.11.2

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Thursday, December 29, 2011 10:36 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 14/14] automake: upgrade from 1.11.1 to
> 1.11.2
> 
> On Thu, Dec 29, 2011 at 04:30:59PM -0800, nitin.a.kam...@intel.com
> wrote:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/recipes-devtools/automake/automake.inc|1 -
> >  .../{automake_1.11.1.bb => automake_1.11.2.bb} |5 +++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)  rename
> > meta/recipes-devtools/automake/{automake_1.11.1.bb =>
> > automake_1.11.2.bb} (88%)
> >
> > diff --git a/meta/recipes-devtools/automake/automake.inc
> > b/meta/recipes-devtools/automake/automake.inc
> > index 25b0c0e..c259673 100644
> > --- a/meta/recipes-devtools/automake/automake.inc
> > +++ b/meta/recipes-devtools/automake/automake.inc
> > @@ -4,7 +4,6 @@ Standards. Automake requires the use of Autoconf."
> >  LICENSE = "GPLv2"
> >  HOMEPAGE = "http://www.gnu.org/software/automake/";
> >  SECTION = "devel"
> > -PR = "r5"
> >
> >  SRC_URI = "${GNU_MIRROR}/automake/automake-${PV}.tar.bz2 "
> >
> > diff --git a/meta/recipes-devtools/automake/automake_1.11.1.bb
> > b/meta/recipes-devtools/automake/automake_1.11.2.bb
> > similarity index 88%
> > rename from meta/recipes-devtools/automake/automake_1.11.1.bb
> > rename to meta/recipes-devtools/automake/automake_1.11.2.bb
> > index ff8353f..18436d2 100644
> > --- a/meta/recipes-devtools/automake/automake_1.11.1.bb
> > +++ b/meta/recipes-devtools/automake/automake_1.11.2.bb
> > @@ -37,8 +37,9 @@ SRC_URI += "${PATHFIXPATCH} \
> > file://prefer-cpio-over-pax-for-ustar-archives.patch \
> > file://python-libdir.patch"
> >
> > -SRC_URI[md5sum] = "c2972c4d9b3e29c03d5f2af86249876f"
> > -SRC_URI[sha256sum] =
> "5b159d3c0e0a1f87de71b68bcb9f1a1c49e9e71749c9b723f17e2e1e0295c7ae"
> > +PR=r0
> 
> Just style issue but please add spaces and quotes.
Thanks for catching this. I have fixed it on the contrib branch: 
nitin/upgrades+fixes

Thanks,
Nitin

> 
> > +SRC_URI[md5sum] = "18194e804d415767bae8f703c963d456"
> > +SRC_URI[sha256sum] =
> "4f46d1f9380c8a3506280750f630e9fc915cb1a435b724be56b499d016368718"
> >
> >  do_install () {
> > oe_runmake 'DESTDIR=${D}' install
> > --
> > 1.7.6.4
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

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

Re: [OE-core] [PATCH 1/1] mc: fix configure with automake 1.11.2

[Kamble, Nitin A]

Samual,
  Thank you for this update of automake issue. I also notice that the patch to 
fix has gone in the automake development branch. I will add it to our automake 
recipe.

Nitin


> -Original Message-
> From: Samuel Stirtzel [mailto:s.stirt...@googlemail.com]
> Sent: Thursday, January 05, 2012 7:07 AM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCH 1/1] mc: fix configure with automake
> 1.11.2
> 
> 2012/1/4 Dexuan Cui :
> > As Nitin said, "automake version 1.11.2 has made use of dir variables
> > more strict, the pkglibexec var can not have SCRIPTS suffix. Using
> pkgdata
> > instead."
> >
> Actually this is a Automake inconsistency, it should be possible to
> use pkglibexec with SCRIPTS suffix as stated in the manual [1].
> After experiencing some build errors of this type, while building
> commonly used software, I searched around and this thread came to my
> attention:
> http://lists.gnu.org/archive/html/automake/2012-01/msg2.html
> 
> [1] Automake variable uniformity:
> http://www.gnu.org/software/automake/manual/html_node/Uniform.html
> 
> --
> Regards
> Samuel
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] eglibc: Upgrade recipes 2.14 -> 2.15

[Kamble, Nitin A]

Can this be done without removing eglibc 2.14 recipe files ?

X32 layer is depending on the eglibc-2.14 recipe.

Thanks,
Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Thursday, January 05, 2012 7:40 PM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] eglibc: Upgrade recipes 2.14 -> 2.15
> 
> Signed-off-by: Khem Raj 
> ---
>  ...tive_2.14.bb => cross-localedef-native_2.15.bb} |0
>  .../IO-acquire-lock-fix.patch  |0
>  .../armv4-eabi-compile-fix.patch   |0
>  .../eglibc-rpc-export-again.patch  |0
>  .../eglibc-svn-arm-lowlevellock-include-tls.patch  |0
>  .../{eglibc-2.14 => eglibc-2.15}/etc/ld.so.conf|0
>  .../generate-supported.mk  |0
>  .../glibc-2.14-libdl-crash.patch   |0
>  .../ld-search-order.patch  |0
>  .../mips-rld-map-check.patch   |0
>  .../multilib_readlib.patch |0
>  .../{eglibc-2.14 => eglibc-2.15}/ppc-sqrt.patch|0
>  .../stack-protector-test.patch |0
>  .../use-sysroot-cxx-headers.patch  |   30
> 
>  .../recipes-core/eglibc/eglibc-2.15/x86_fenv.patch |   29
> +++
>  ...libc-initial_2.14.bb => eglibc-initial_2.15.bb} |0
>  ...eglibc-locale_2.14.bb => eglibc-locale_2.15.bb} |0
>  .../eglibc/{eglibc_2.14.bb => eglibc_2.15.bb}  |   15 --
>  18 files changed, 59 insertions(+), 15 deletions(-)
>  rename meta/recipes-core/eglibc/{cross-localedef-native_2.14.bb =>
> cross-localedef-native_2.15.bb} (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/IO-
> acquire-lock-fix.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/armv4-
> eabi-compile-fix.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/eglibc-
> rpc-export-again.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/eglibc-
> svn-arm-lowlevellock-include-tls.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-
> 2.15}/etc/ld.so.conf (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/generate-
> supported.mk (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/glibc-
> 2.14-libdl-crash.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/ld-
> search-order.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/mips-rld-
> map-check.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-
> 2.15}/multilib_readlib.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/ppc-
> sqrt.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/stack-
> protector-test.patch (100%)
>  rename meta/recipes-core/eglibc/{eglibc-2.14 => eglibc-2.15}/use-
> sysroot-cxx-headers.patch (51%)
>  create mode 100644 meta/recipes-core/eglibc/eglibc-2.15/x86_fenv.patch
>  rename meta/recipes-core/eglibc/{eglibc-initial_2.14.bb => eglibc-
> initial_2.15.bb} (100%)
>  rename meta/recipes-core/eglibc/{eglibc-locale_2.14.bb => eglibc-
> locale_2.15.bb} (100%)
>  rename meta/recipes-core/eglibc/{eglibc_2.14.bb => eglibc_2.15.bb}
> (95%)
> 
> diff --git a/meta/recipes-core/eglibc/cross-localedef-native_2.14.bb
> b/meta/recipes-core/eglibc/cross-localedef-native_2.15.bb
> similarity index 100%
> rename from meta/recipes-core/eglibc/cross-localedef-native_2.14.bb
> rename to meta/recipes-core/eglibc/cross-localedef-native_2.15.bb
> diff --git a/meta/recipes-core/eglibc/eglibc-2.14/IO-acquire-lock-
> fix.patch b/meta/recipes-core/eglibc/eglibc-2.15/IO-acquire-lock-
> fix.patch
> similarity index 100%
> rename from meta/recipes-core/eglibc/eglibc-2.14/IO-acquire-lock-
> fix.patch
> rename to meta/recipes-core/eglibc/eglibc-2.15/IO-acquire-lock-
> fix.patch
> diff --git a/meta/recipes-core/eglibc/eglibc-2.14/armv4-eabi-compile-
> fix.patch b/meta/recipes-core/eglibc/eglibc-2.15/armv4-eabi-compile-
> fix.patch
> similarity index 100%
> rename from meta/recipes-core/eglibc/eglibc-2.14/armv4-eabi-compile-
> fix.patch
> rename to meta/recipes-core/eglibc/eglibc-2.15/armv4-eabi-compile-
> fix.patch
> diff --git a/meta/recipes-core/eglibc/eglibc-2.14/eglibc-rpc-export-
> again.patch b/meta/recipes-core/eglibc/eglibc-2.15/eglibc-rpc-export-
> again.patch
> similarity index 100%
> rename from meta/recipes-core/eglibc/eglibc-2.14/eglibc-rpc-export-
> again.patch
> rename to meta/recipes-core/eglibc/eglibc-2.15/eglibc-rpc-export-
> again.patch
> diff --git a/meta/recipes-core/eglibc/eglibc-2.14/eglibc-svn-arm-
> lowlevellock-include-tls.patch b/meta/recipes-core/eglibc/eglibc-
> 2.15/eglibc-svn-arm-lowlevellock-include-tls.patch
> similarity index 100%
> rename from me

Re: [OE-core] [PATCH] eglibc: Upgrade recipes 2.14 -> 2.15

[Kamble, Nitin A]

> -Original Message-
> From: Saul Wold [mailto:s...@linux.intel.com]
> Sent: Thursday, January 05, 2012 11:10 PM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCH] eglibc: Upgrade recipes 2.14 -> 2.15
> 
> On 01/05/2012 08:59 PM, Kamble, Nitin A wrote:
> > Can this be done without removing eglibc 2.14 recipe files ?
> >
> > X32 layer is depending on the eglibc-2.14 recipe.
> >
> Can this 2.15 recipe be updated for x32?


That is a big change for x32, It may work out or not, last time x32 + 
eglibc-2.15 was causing some issues which were I think actually more 
eglibc-2.15 issues. The worst case is I can move the eglibc-2.14 recipe into 
the meta-x32 layer.

Thanks,
Nitin



> 
> Sau!
> > Thanks,
> > Nitin
> >
> >
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> >> Khem Raj
> >> Sent: Thursday, January 05, 2012 7:40 PM
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: [OE-core] [PATCH] eglibc: Upgrade recipes 2.14 ->  2.15
> >>
> >> Signed-off-by: Khem Raj
> >> ---
> >>   ...tive_2.14.bb =>  cross-localedef-native_2.15.bb} |0
> >>   .../IO-acquire-lock-fix.patch  |0
> >>   .../armv4-eabi-compile-fix.patch   |0
> >>   .../eglibc-rpc-export-again.patch  |0
> >>   .../eglibc-svn-arm-lowlevellock-include-tls.patch  |0
> >>   .../{eglibc-2.14 =>  eglibc-2.15}/etc/ld.so.conf|0
> >>   .../generate-supported.mk  |0
> >>   .../glibc-2.14-libdl-crash.patch   |0
> >>   .../ld-search-order.patch  |0
> >>   .../mips-rld-map-check.patch   |0
> >>   .../multilib_readlib.patch |0
> >>   .../{eglibc-2.14 =>  eglibc-2.15}/ppc-sqrt.patch|0
> >>   .../stack-protector-test.patch |0
> >>   .../use-sysroot-cxx-headers.patch  |   30
> >> 
> >>   .../recipes-core/eglibc/eglibc-2.15/x86_fenv.patch |   29
> >> +++
> >>   ...libc-initial_2.14.bb =>  eglibc-initial_2.15.bb} |0
> >>   ...eglibc-locale_2.14.bb =>  eglibc-locale_2.15.bb} |0
> >>   .../eglibc/{eglibc_2.14.bb =>  eglibc_2.15.bb}  |   15
> --
> >>   18 files changed, 59 insertions(+), 15 deletions(-)
> >>   rename meta/recipes-core/eglibc/{cross-localedef-native_2.14.bb =>
> >> cross-localedef-native_2.15.bb} (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-2.15}/IO-
> >> acquire-lock-fix.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-
> 2.15}/armv4-
> >> eabi-compile-fix.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-
> 2.15}/eglibc-
> >> rpc-export-again.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-
> 2.15}/eglibc-
> >> svn-arm-lowlevellock-include-tls.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-
> >> 2.15}/etc/ld.so.conf (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-
> 2.15}/generate-
> >> supported.mk (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-
> 2.15}/glibc-
> >> 2.14-libdl-crash.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-2.15}/ld-
> >> search-order.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-
> 2.15}/mips-rld-
> >> map-check.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-
> >> 2.15}/multilib_readlib.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-2.15}/ppc-
> >> sqrt.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-
> 2.15}/stack-
> >> protector-test.patch (100%)
> >>   rename meta/recipes-core/eglibc/{eglibc-2.14 =>  eglibc-2.15}/use-
> >> sysroot-cxx-headers.patch (51%)
> >>   create mode 100644 meta/recipes-core/eglibc/eglibc-
> 2.15/x86_fenv.patch
> >>   rename meta/recipes-core/eglibc/{eglibc-initial_2.14.bb =>
> eglibc-
> >> initial_2.15.bb} (100%)
> >>   rename meta/recipes-core/eglib

Re: [OE-core] [PATCH 3/4] libxxf86dga: fix compilation with x32 toolchain

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Thursday, January 05, 2012 12:49 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 3/4] libxxf86dga: fix compilation with
> x32 toolchain
> 
> On Wed, Jan 4, 2012 at 5:02 PM,   wrote:
> > From: Nitin A Kamble 
> >
> > Fix type conversion for x32. For x32 the off_t is 64bit and pointers
> are
> > 32bit.
> > so the conversion of pointer to off_t was resulting into this error:
> >
> > | XF86DGA2.c:931:24: error: cast from pointer to integer of different
> > size [-Werror=pointer-to-int-cast]
> > | cc1: some warnings being treated as errors
> > |
> > | make[2]: *** [XF86DGA2.lo] Error 1
> >
> > Fixed it by typecasting pointer into unsigned long 1st and then again
> > typecasting unsigned long to off_t.
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../libxxf86dga-1.1.2_fix_for_x32.patch            |   30
> 
> >  .../recipes-graphics/xorg-lib/libxxf86dga_1.1.2.bb |    5 ++-
> >  2 files changed, 34 insertions(+), 1 deletions(-)
> >  create mode 100644 meta/recipes-graphics/xorg-
> lib/libxxf86dga/libxxf86dga-1.1.2_fix_for_x32.patch
> >
> > diff --git a/meta/recipes-graphics/xorg-lib/libxxf86dga/libxxf86dga-
> 1.1.2_fix_for_x32.patch b/meta/recipes-graphics/xorg-
> lib/libxxf86dga/libxxf86dga-1.1.2_fix_for_x32.patch
> > new file mode 100644
> > index 000..30692ad
> > --- /dev/null
> > +++ b/meta/recipes-graphics/xorg-lib/libxxf86dga/libxxf86dga-
> 1.1.2_fix_for_x32.patch
> > @@ -0,0 +1,30 @@
> > +Upstream-Status: pending
> > +
> > +Fix type conversion for x32. For x32 the off_t is 64bit and pointers
> are 32bit.
> > +so the conversion of pointer to off_t was resulting into this error:
> > +
> > +| XF86DGA2.c:931:24: error: cast from pointer to integer of
> different size [-Werror=pointer-to-int-cast]
> > +| cc1: some warnings being treated as errors
> > +|
> > +| make[2]: *** [XF86DGA2.lo] Error 1
> > +
> > +Fixed it by typecasting pointer into unsigned long 1st and then
> again typecasting
> > +unsigned long to off_t.
> 
> where is pointer here ?
> http://cvsweb.xfree86.org/cvsweb/xc/lib/Xxf86dga/XF86DGA2.c?rev=1.30&co
> ntent-type=text/vnd.viewcvs-markup
> shows that base is of type mmapOffset which is
> 
> #if !defined(_LP64) && defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS
> == 64)
> typedef unsigned long long mmapOffset;
> #else
> typedef unsigned long  mmapOffset;
> #endif
> 
> and off_t is typedef'ed to long int
> 
Khem,
base is char * as seen in the changed file src/XF86DGA2.c:
static Bool
DGAMapPhysical(
   int screen,
   char *name,  /* optional device name */
   unsigned char* base, /* physical memory */
   CARD32 size, /* size */
   CARD32 offset,   /* optional offset */
   CARD32 extra,/* optional extra data */
   DGAMapPtr pMap
) {

Nitin

> > +
> > +Signed-Off-by: Nitin A Kamble 
> > +2012/01/04
> > +
> > +
> > +Index: libXxf86dga-1.1.2/src/XF86DGA2.c
> > +===
> > +--- libXxf86dga-1.1.2.orig/src/XF86DGA2.c      2010-10-06
> 21:17:11.0 -0700
> >  libXxf86dga-1.1.2/src/XF86DGA2.c   2012-01-04 14:21:36.275971172
> -0800
> > +@@ -928,7 +928,7 @@ DGAMapPhysical(
> > +     if ((pMap->fd = open(name, O_RDWR)) < 0)
> > +       return False;
> > +     pMap->virtual = mmap(NULL, size, PROT_READ | PROT_WRITE,
> > +-                      MAP_FILE | MAP_SHARED, pMap->fd,
> (off_t)base);
> > ++                      MAP_FILE | MAP_SHARED, pMap->fd,
> (off_t)(unsigned long)base);
> > +     if (pMap->virtual == (void *)-1)
> > +       return False;
> > +     mprotect(pMap->virtual, size, PROT_READ | PROT_WRITE);
> > diff --git a/meta/recipes-graphics/xorg-lib/libxxf86dga_1.1.2.bb
> b/meta/recipes-graphics/xorg-lib/libxxf86dga_1.1.2.bb
> > index 8e777c3..9a1c96f 100644
> > --- a/meta/recipes-graphics/xorg-lib/libxxf86dga_1.1.2.bb
> > +++ b/meta/recipes-graphics/xorg-lib/libxxf86dga_1.1.2.bb
> > @@ -8,7 +8,10 @@ allows relative mouse reporting, et al.  It is
> mainly used by games and \
> >  emulators for games."
> >
> >  DEPENDS += "libxext xf86dgaproto"
> > -PR = "r1"
> > +PR = "r2"
> > +
> > +SRC_URI += "file://libxxf86dga-1.1.2_fix_for_x32.patch"
> > +
> >  PE = "1"
> >
> >  XORG_PN = "libXxf86dga"
> > --
> > 1.7.6.4
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@

Re: [OE-core] [PATCH] eglibc: Upgrade recipes 2.14 -> 2.15

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Friday, January 06, 2012 3:09 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH] eglibc: Upgrade recipes 2.14 -> 2.15
> 
> On Fri, Jan 6, 2012 at 10:07 AM, Kamble, Nitin A
>  wrote:
> > That is a big change for x32, It may work out or not, last time x32 +
> eglibc-2.15 was causing some issues which were I think actually more
> eglibc-2.15 issues. The worst case is I can move the eglibc-2.14 recipe
> into the meta-x32 layer.
> 
> If you are not on a release trail I would suggest to try 2.15. You can
> move the recipes to a
> layer certainly but its better to keep less versions around for
> maintenance sake. what problems do u envision that can happen with
> 2.15 ?

I do not remember all the issues now, but I was seeing more failures. I can 
give it a try with 2.15 and see how it goes.

Thanks,
Nitin

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

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

Re: [OE-core] [PATCH 5/5] grub-efi-native: fix errors with automake 1.11.2

[Kamble, Nitin A]

> -Original Message-
> From: Saul Wold [mailto:s...@linux.intel.com]
> Sent: Tuesday, January 17, 2012 1:45 PM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCH 5/5] grub-efi-native: fix errors with
> automake 1.11.2
> 
> On 01/17/2012 12:30 PM, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble
> >
> > This commit replaces earlier patch
> > (grub-1.99_fix_for_automake_1.11.2.patch) which did not work on all
> distros.
> >
> > Fixes these errors observed with automake 1.11.2
> > The useof pkglibhas become more strict compared to the earlier
> release
> > of
> > automake resulting in these failures.
> > Fixed the files related to automake to avoid the issue.
> >
> > | conf/Makefile.common:140: `pkglibdir' is not a legitimate directory
> > for `DATA'
> > | grub-core/Makefile.am:5:   `conf/Makefile.common' included from
> here
> > | conf/Makefile.common:140: `pkglibdir' is not a legitimate directory
> > for `DATA'
> > | Makefile.am:6:   `conf/Makefile.common' included from here
> > | autoreconf: automake failed with exit status: 1
> > | ERROR: autoreconf execution failed.
> >
> > | conf/Makefile.common:150: `pkglibdir' is not a legitimate directory
> > for `SCRIPTS'
> > | grub-core/Makefile.am:5:   `conf/Makefile.common' included from
> here
> > | conf/Makefile.common:140: `pkglibdir' is not a legitimate directory
> > for `DATA'
> > | grub-core/Makefile.am:5:   `conf/Makefile.common' included from
> here
> > | conf/Makefile.common:150: `pkglibdir' is not a legitimate directory
> > for `SCRIPTS'
> > | Makefile.am:6:   `conf/Makefile.common' included from here
> > | conf/Makefile.common:140: `pkglibdir' is not a legitimate directory
> > for `DATA'
> > | Makefile.am:6:   `conf/Makefile.common' included from here
> > | autoreconf: automake failed with exit status: 1
> >
> > Signed-off-by: Nitin A Kamble
> > ---
> >   .../files/grub-1.99_fix_for_automake_1.11.2.patch  | 5808 -
> ---
> >   meta/recipes-bsp/grub/grub-efi-native_1.99.bb  |4 +-
> >   2 files changed, 2 insertions(+), 5810 deletions(-)
> >
> > diff --git a/meta/recipes-bsp/grub/files/grub-
> 1.99_fix_for_automake_1.11.2.patch b/meta/recipes-bsp/grub/files/grub-
> 1.99_fix_for_automake_1.11.2.patch
> > index 1c70e4a..4d729e5 100644
> > --- a/meta/recipes-bsp/grub/files/grub-
> 1.99_fix_for_automake_1.11.2.patch
> > +++ b/meta/recipes-bsp/grub/files/grub-
> 1.99_fix_for_automake_1.11.2.patch
> > @@ -65,5612 +65,6 @@ Index: grub-1.99/Makefile.am
> >
> >
> Missing Patch header with Upstream-Status: and Signed-off-by:
> 
> Sau!
Saul,
  It is not missing: 
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/tree/meta/recipes-bsp/grub/files/grub-1.99_fix_for_automake_1.11.2.patch?h=nitin/misc&id=c81dac1964de6f926fce11c00f2a90a7ed76d577

Nitin

> 
> >if COND_i386_coreboot
> > -Index: grub-1.99/Makefile.tpl
> > -===
> >  grub-1.99.orig/Makefile.tpl
> > -+++ grub-1.99/Makefile.tpl
> 
> 
> 
> > - CLEANFILES += genmod.sh
> > diff --git a/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
> b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
> > index b976d1e..dfa4725 100644
> > --- a/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
> > +++ b/meta/recipes-bsp/grub/grub-efi-native_1.99.bb
> > @@ -14,9 +14,9 @@ LICENSE = "GPLv3"
> >   LIC_FILES_CHKSUM =
> "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> >
> >   # FIXME: We should be able to optionally drop freetype as a
> dependency
> > -DEPENDS = "help2man-native"
> > +DEPENDS = "help2man-native autogen-native"
> >   RDEPENDS_${PN} = "diffutils freetype"
> > -PR = "r3"
> > +PR = "r4"
> >
> >   # Native packages do not normally rebuild when the target changes.
> >   # Ensure this is built once per HOST-TARGET pair.

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

Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Flanagan, Elizabeth
> Sent: Tuesday, January 17, 2012 2:21 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen
> 
> On Tue, Jan 17, 2012 at 1:43 PM, Saul Wold  wrote:
> > On 01/17/2012 12:30 PM, nitin.a.kam...@intel.com wrote:
> >>
> >> From: Nitin A Kamble
> >>
> >> This recipe is needed by guile.
> >> And guile is needed for autogen.
> >>
> >> Signed-off-by: Nitin A Kamble
> >> ---
> >>  meta/recipes-support/bdwgc/bdwgc_20110107.bb |   38
> >> ++
> >>  1 files changed, 38 insertions(+), 0 deletions(-)
> >>  create mode 100644 meta/recipes-support/bdwgc/bdwgc_20110107.bb
> >>
> >> diff --git a/meta/recipes-support/bdwgc/bdwgc_20110107.bb
> >> b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
> >> new file mode 100644
> >> index 000..1aaa5b8
> >> --- /dev/null
> >> +++ b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
> >> @@ -0,0 +1,38 @@
> >> +SUMMARY = "A garbage collector for C and C++"
> >> +
> >> +DESCRIPTION = "The Boehm-Demers-Weiser conservative garbage
> collector can
> >> be\
> >> + used as a garbage collecting replacement for C malloc or C++ new.
> It
> >> allows\
> >> + you to allocate memory basically as you normally would, without
> >> explicitly\
> >> + deallocating memory that is no longer useful. The collector
> >> automatically\
> >> + recycles memory when it determines that it can no longer be
> otherwise\
> >> + accessed.\
> >> +  The collector is also used by a number of programming language\
> >> + implementations that either use C as intermediate code, want to
> >> facilitate\
> >> + easier interoperation with C libraries, or just prefer the simple
> >> collector\
> >> + interface.\
> >> +  Alternatively, the garbage collector may be used as a leak
> detector for
> >> C\
> >> + or C++ programs, though that is not its primary goal.\
> >> +  Empirically, this collector works with most unmodified C
> programs,
> >> simply\
> >> + by replacing malloc with GC_malloc calls, replacing realloc with
> >> GC_realloc\
> >> + calls, and removing free calls."
> >> +
> >> +HOMEPAGE = "http://www.hpl.hp.com/personal/Hans_Boehm/gc/";
> >> +SECTION = "devel"
> >> +LICENSE = "custom"
> >
> > What's custom?  Is this the correct LICENSE name to use here?
> > Beth comments?
> 
> custom is certainly not correct. This one isn't a particularly easy
> one.
> 
> openSuSE says BSD-3-Clause. This isn't actually true from what I'm
> seeing. It looks to me more like:
> 
> LICENSE = "MIT & FSF-Unlimited & GPL-2.0"
> 
> linux_threads.c and Makefile.am appear to be MIT.
> 
> "Several files supporting GNU-style builds are copyrighted by the Free
> Software Foundation, and carry a different license from that given
> below." I would assume that that is FSF-Unlimited.
> 
> The main portion of the license is MIT.
> 
> It does mention that there are some GPL code in here:
> 
> "A few of the files needed to use the GNU-style build procedure come
> with
> slightly different licenses, though they are all similar in spirit.  A
> few
> are GPL'ed, but with an exception that should cover all uses in the
> collector.  (If you are concerned about such things, I recommend you
> look
> at the notice in config.guess or ltmain.sh.)"
> 
> ltmain.sh is GPL-2.0. Is it distributed in the package? If so, then I
> would add it to LICENSE.
Beth,
 As seen in the sources: http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/
The ltmain.sh is part of the source. So as per your recommendation I am setting
LICENSE = "MIT & FSF-Unlimited & GPL-2.0"

Thanks,
Nitin

> 
> Doing above should cover all bases.
> 
> -b
> 
> >
> > Sau!
> >
> >
> >> +LIC_FILES_CHKSUM =
> >> "file://README.QUICK;md5=9b9dd874f6940641b6ab19893ee8f1cc"
> >> +
> >> +SRC_URI =
> >> "http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/bdwgc-
> 7_2alpha5-20110107.tar.bz2"
> >> +
> >> +SRC_URI[md5sum] = "4f3c130fc71ff23584edaa19a37739ee"
> >> +SRC_URI[sha256sum] =
> >> "1f57b959ae1144e1e5fa59d52d7cb4ed626fd74cf47da1c9c119b8b46ae2722d"
> >> +
> >> +PR = "r0"
> >> +
> >> +S = "${WORKDIR}/bdwgc"
> >> +
> >> +do_install_append (){
> >> +       rm -f ${D}${datadir}/${PN}
> >> +}
> >> +
> >> +inherit autotools
> >> +BBCLASSEXTEND = "native nativesdk"
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> 
> --
> Elizabeth Flanagan
> Yocto Project
> Build and Release
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.op

Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen

[Kamble, Nitin A]

Khem,
Here was the configure error:
| configure: error: Package requirements (bdw-gc) were not met:
| 
| No package 'bdw-gc' found
| 
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
| 
| Alternatively, you may set the environment variables BDW_GC_CFLAGS
| and BDW_GC_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
| ERROR: oe_runconf failed

Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Tuesday, January 17, 2012 3:23 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen
> 
> On Tue, Jan 17, 2012 at 12:30 PM,   wrote:
> > This recipe is needed by guile.
> > And guile is needed for autogen.
> 
> is this really needed by guile. if yes what part of guide need it ?
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Kamble, Nitin A
> Sent: Tuesday, January 17, 2012 5:29 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen
> 
> Khem,
> Here was the configure error:
> | configure: error: Package requirements (bdw-gc) were not met:
> |
> | No package 'bdw-gc' found
> |
> | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> | installed software in a non-standard prefix.
> |
> | Alternatively, you may set the environment variables BDW_GC_CFLAGS
> | and BDW_GC_LIBS to avoid the need to call pkg-config.
> | See the pkg-config man page for more details.
> | ERROR: oe_runconf failed
> 
> Nitin
> 
And it is being used in this c file: libguile/threads.c

Thanks,
Nitin

> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> > Khem Raj
> > Sent: Tuesday, January 17, 2012 3:23 PM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen
> >
> > On Tue, Jan 17, 2012 at 12:30 PM,   wrote:
> > > This recipe is needed by guile.
> > > And guile is needed for autogen.
> >
> > is this really needed by guile. if yes what part of guide need it ?
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Tuesday, January 17, 2012 9:46 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen
> 
> On Tue, Jan 17, 2012 at 5:33 PM, Kamble, Nitin A
>  wrote:
> >
> >
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> >> Kamble, Nitin A
> >> Sent: Tuesday, January 17, 2012 5:29 PM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen
> >>
> >> Khem,
> >> Here was the configure error:
> >> | configure: error: Package requirements (bdw-gc) were not met:
> >> |
> >> | No package 'bdw-gc' found
> >> |
> >> | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> >> | installed software in a non-standard prefix.
> >> |
> >> | Alternatively, you may set the environment variables BDW_GC_CFLAGS
> >> | and BDW_GC_LIBS to avoid the need to call pkg-config.
> >> | See the pkg-config man page for more details.
> >> | ERROR: oe_runconf failed
> 
> yeah I see guile-2 needs a garbage collector. Did you try the original
> libgc ?
> http://anonscm.debian.org/gitweb/?p=collab-maint/libgc.git;a=summary
> 

Khem,
  As the bdwgc was working as expected, I did not try to find any alternative 
there.
Nitin

> 
> >>
> >> Nitin
> >>
> > And it is being used in this c file: libguile/threads.c
> >
> > Thanks,
> > Nitin
> >
> >>
> >> > -Original Message-
> >> > From: openembedded-core-boun...@lists.openembedded.org
> >> > [mailto:openembedded-core-boun...@lists.openembedded.org] On
> Behalf
> >> Of
> >> > Khem Raj
> >> > Sent: Tuesday, January 17, 2012 3:23 PM
> >> > To: Patches and discussions about the oe-core layer
> >> > Subject: Re: [OE-core] [PATCH 1/5] bdwgc: new recipe for autogen
> >> >
> >> > On Tue, Jan 17, 2012 at 12:30 PM,  
> wrote:
> >> > > This recipe is needed by guile.
> >> > > And guile is needed for autogen.
> >> >
> >> > is this really needed by guile. if yes what part of guide need it
> ?
> >> >
> >> > ___
> >> > Openembedded-core mailing list
> >> > Openembedded-core@lists.openembedded.org
> >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> core
> >>
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
> core
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/5] guile: new recipe for autogen

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Wednesday, January 18, 2012 1:54 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 3/5] guile: new recipe for autogen
> 
> 
> Op 17 jan. 2012, om 21:30 heeft nitin.a.kam...@intel.com het volgende
> geschreven:
> 
> > From: Nitin A Kamble 
> >
> > guile recipe is needed by autogen.
> 
> How much does this differ from the guile in meta-oe?

Koen,
  I could not get the guide-config-cross stuff working with this version. 
I don't understand guile that well to fix this. 
Who created the guilt recipes in meta-oe ? 
Other than that I don't see any functional differences other than newer
Version.

Nitin


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

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

Re: [OE-core] [PATCH 3/5] guile: new recipe for autogen

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Kamble, Nitin A
> Sent: Wednesday, January 18, 2012 1:09 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 3/5] guile: new recipe for autogen
> 
> 
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> > Koen Kooi
> > Sent: Wednesday, January 18, 2012 1:54 AM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [PATCH 3/5] guile: new recipe for autogen
> >
> >
> > Op 17 jan. 2012, om 21:30 heeft nitin.a.kam...@intel.com het volgende
> > geschreven:
> >
> > > From: Nitin A Kamble 
> > >
> > > guile recipe is needed by autogen.
> >
> > How much does this differ from the guile in meta-oe?
> 
> Koen,
>   I could not get the guide-config-cross stuff working with this
> version.
> I don't understand guile that well to fix this.
> Who created the guilt recipes in meta-oe ?
> Other than that I don't see any functional differences other than newer
> Version.
> 
> Nitin


I spent more time, and could get the guile-config-cross stuff working in the 
newer recipe.
So with this in the meta-oe guile recipes can be removed.

Nitin

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

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

Re: [OE-core] [PATCHv3 2/7] bdwgc: new recipe for autogen

[Kamble, Nitin A]

> -Original Message-
> From: Saul Wold [mailto:s...@linux.intel.com]
> Sent: Wednesday, January 18, 2012 5:15 PM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCHv3 2/7] bdwgc: new recipe for autogen
> 
> On 01/18/2012 03:32 PM, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble
> >
> > This recipe is needed by guile.
> > And guile is needed for autogen.
> >
> > As per Beth's recommondation changed the license specification of the
> > recipe as
> >
> > LICENSE = "MIT&  FSF-Unlimited&  GPL-2.0"
> >
> > Signed-off-by: Nitin A Kamble
> > ---
> >   meta/recipes-support/bdwgc/bdwgc_20110107.bb |   40
> ++
> >   1 files changed, 40 insertions(+), 0 deletions(-)
> >   create mode 100644 meta/recipes-support/bdwgc/bdwgc_20110107.bb
> >
> > diff --git a/meta/recipes-support/bdwgc/bdwgc_20110107.bb
> b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
> > new file mode 100644
> > index 000..1e32681
> > --- /dev/null
> > +++ b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
> > @@ -0,0 +1,40 @@
> > +SUMMARY = "A garbage collector for C and C++"
> > +
> > +DESCRIPTION = "The Boehm-Demers-Weiser conservative garbage
> collector can be\
> > + used as a garbage collecting replacement for C malloc or C++ new.
> It allows\
> > + you to allocate memory basically as you normally would, without
> explicitly\
> > + deallocating memory that is no longer useful. The collector
> automatically\
> > + recycles memory when it determines that it can no longer be
> otherwise\
> > + accessed.\
> > +  The collector is also used by a number of programming language\
> > + implementations that either use C as intermediate code, want to
> facilitate\
> > + easier interoperation with C libraries, or just prefer the simple
> collector\
> > + interface.\
> > +  Alternatively, the garbage collector may be used as a leak
> detector for C\
> > + or C++ programs, though that is not its primary goal.\
> > +  Empirically, this collector works with most unmodified C programs,
> simply\
> > + by replacing malloc with GC_malloc calls, replacing realloc with
> GC_realloc\
> > + calls, and removing free calls."
> > +
> > +HOMEPAGE = "http://www.hpl.hp.com/personal/Hans_Boehm/gc/";
> > +SECTION = "devel"
> > +LICENSE = "MIT&  FSF-Unlimited&  GPL-2.0"
> > +LIC_FILES_CHKSUM =
> "file://README.QUICK;md5=9b9dd874f6940641b6ab19893ee8f1cc \
> > +
> file://doc/README;md5=6d74ce18ff55d936a4d6bd35a98e9eb9 \
> > +
> file://libatomic_ops/doc/LICENSING.txt;md5=607073e04548eac7d1f763e48047
> 7bab"
> > +
> > +SRC_URI =
> "http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/bdwgc-
> 7_2alpha5-20110107.tar.bz2"
> > +
> > +SRC_URI[md5sum] = "4f3c130fc71ff23584edaa19a37739ee"
> > +SRC_URI[sha256sum] =
> "1f57b959ae1144e1e5fa59d52d7cb4ed626fd74cf47da1c9c119b8b46ae2722d"
> > +
> > +PR = "r0"
> > +
> > +S = "${WORKDIR}/bdwgc"
> > +
> > +do_install_append (){
> > +   rm -rf ${D}${datadir}/gc
> > +}
> > +
> > +inherit autotools
> > +BBCLASSEXTEND = "native nativesdk"
> 
> Nitin,
> 
> I am seeing the following WARNING, can you please fix this
> WARNING: For recipe bdwgc, the following files/directories were
> installed but not shipped in any package:
> WARNING:   /usr/share
> 
> Thanks
>   Sau!
Fixed this on the contrib. branch.
Thanks,
Nitin


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

Re: [OE-core] [PATCHv3 3/7] libunistring: new recipe for autogen

[Kamble, Nitin A]

> -Original Message-
> From: Saul Wold [mailto:s...@linux.intel.com]
> Sent: Wednesday, January 18, 2012 5:16 PM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCHv3 3/7] libunistring: new recipe for
> autogen
> 
> On 01/18/2012 03:32 PM, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble
> >
> > libunistring recipe is needed by guile.
> > And guile is needed by autogen.
> >
> > Signed-off-by: Nitin A Kamble
> > ---
> >   .../libunistring/libunistring_0.9.3.bb |   27
> 
> >   1 files changed, 27 insertions(+), 0 deletions(-)
> >   create mode 100644 meta/recipes-
> support/libunistring/libunistring_0.9.3.bb
> >
> > diff --git a/meta/recipes-support/libunistring/libunistring_0.9.3.bb
> b/meta/recipes-support/libunistring/libunistring_0.9.3.bb
> > new file mode 100644
> > index 000..7d09761
> > --- /dev/null
> > +++ b/meta/recipes-support/libunistring/libunistring_0.9.3.bb
> > @@ -0,0 +1,27 @@
> > +SUMMARY = "libunistring provides functions for manipulating
> according to the Unicode standard."
> > +
> > +DESCRIPTION = "Text files are nowadays usually encoded in Unicode,
> and may consist of very\
> > + different scripts – from Latin letters to Chinese Hanzi –, with
> many kinds of special\
> > + characters – accents, right-to-left writing marks, hyphens, Roman
> numbers, and much\
> > + more. But the POSIX platform APIs for text do not contain adequate
> functions for\
> > + dealing with particular properties of many Unicode characters. In
> fact, the POSIX\
> > + APIs for text have several assumptions at their base which don't
> hold for Unicode\
> > + text. \
> > + This library provides functions for manipulating Unicode strings
> and for manipulating\
> > + C strings according to the Unicode standard."
> > +
> > +HOMEPAGE = "http://www.gnu.org/software/libunistring/";
> > +SECTION = "devel"
> > +LICENSE = "GPLv3&LGPLv3"
> > +LIC_FILES_CHKSUM =
> "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
> > +
> file://COPYING.LIB;md5=6a6a8e020838b23406c81b19c1d46df6"
> > +
> > +SRC_URI = "${GNU_MIRROR}/libunistring/libunistring-${PV}.tar.gz"
> > +
> > +SRC_URI[md5sum] = "db8eca3b64163abadf8c40e5cecc261f"
> > +SRC_URI[sha256sum] =
> "610d3ec724fbdaa654afe3cff20b9f4d504be3fd296fded2e0f7f764041006a3"
> > +
> > +PR = "r0"
> > +
> > +inherit autotools
> > +BBCLASSEXTEND = "native nativesdk"
> 
> Nitin,
> 
> Still seeing, the following:
Rootcaused this as some Unicode characters present in the DESCRIPTION field. 
Fixed it an updated the contrib branch nitin/misc for that.

Nitin

> 
> NOTE: package libunistring-0.9.3-r1: task do_package_write_deb: Started
> ERROR: Error executing a python function in
> /intel/poky/distro/meta/recipes-
> support/libunistring/libunistring_0.9.3.bb:
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
> 96:
> ordinal not in range(128)
> 
> ERROR: The stack trace of python calls that resulted in this
> exception/failure was:
> ERROR:   File "do_package_deb", line 194, in 
> ERROR:
> ERROR:   File "do_package_deb", line 119, in do_package_deb
> ERROR:
> ERROR: The code that was being executed was:
> ERROR:  0190:bb.utils.prunedir(controldir)
> ERROR:  0191:bb.utils.unlockfile(lf)
> ERROR:  0192:
> ERROR:  0193:
> ERROR:  *** 0194:do_package_deb(d)
> ERROR:  0195:
> ERROR: (file: 'do_package_deb', lineno: 194, function: )
> ERROR:  0115: summary =
> localdata.getVar('SUMMARY', True) or localdata.getVar('DESCRIPTION',
> True) or "."
> ERROR:  0116: description =
> localdata.getVar('DESCRIPTION', True) or "."
> ERROR:  0117: description =
> textwrap.dedent(description).strip()
> ERROR:  0118: ctrlfile.write('Description:
> %s\n'
> % unicode(summary))
> ERROR:  *** 0119: ctrlfile.write('%s\n' %
> unicode(textwrap.fill(description, width=74, initial_indent=' ',
> subsequent_indent=' ')))
> ERROR:  0120:else:
> ERROR:  0121: ctrlfile.write(unicode(c %
> tuple(pullData(fs, localdata
> ERROR:  0122:except KeyError:
> ERROR:  0123:import sys
> ERROR: (file: 'do_package_deb', lineno: 119, function: do_package_deb)
> ERROR: Function failed: do_package_deb
> ERROR: Logfile of failure stored in:
> /intel/poky/builds/world/tmp/work/i586-poky-linux/libunistring-0.9.3-
> r1/temp/log.do_package_write_deb.31745
> NOTE: package libunistring-0.9.3-r1: task do_package_write_deb: Failed
> ERROR: Task 646
> (/intel/poky/distro/meta/recipes-
> support/libunistring/libunistring_0.9.3.bb,
> do_package_write_deb) failed with exit code '1'

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

Re: [OE-core] [PATCH 3/8] bdwgc: change the PV

[Kamble, Nitin A]

Lets ignore this commit then. As PV can not take the "_" it does not help me 
achieve what I wanted to. (Internal version tracking system).

Nitin



> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Wednesday, February 01, 2012 2:24 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 3/8] bdwgc: change the PV
> 
> On Wed, 2012-02-01 at 13:55 -0800, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../{bdwgc_20110107.bb => bdwgc_7_2alpha5.bb}  |0
> 
> Why is this a good thing?  Does the "_" in the string actually do what
> you wanted?
> 
> The commit message for this patch is, to put it mildly, poor.  Please
> see:
> 
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#New_De
> velopment
> 
> and, in particular the last two sentences of that section:
> 
> "It is not acceptable to have an empty or non-existent header, or just
> a
> single line message. The summary and description is required for all
> changes."
> 
> p.
> 
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 2/8] gmp: upgrade from 5.0.2 to 5.0.3

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Wednesday, February 01, 2012 2:03 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 2/8] gmp: upgrade from 5.0.2 to 5.0.3
> 
> On Wed, Feb 1, 2012 at 1:55 PM,   wrote:
> >
> > Removed sh4-asmfix.patch as it is not needed with the newer code.
> 
> has it been applied upstream ? or is there any other reason that fixes
> the underlying problem.
The code the patch is patching is restructured in the new version, and looking 
at the patch it is not needed anymore.

Nitin


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

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

Re: [OE-core] [PATCH 7/8] linux-libc-headers: new recipes for latest upstream 3.2.2

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Wednesday, February 01, 2012 2:14 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 7/8] linux-libc-headers: new recipes for
> latest upstream 3.2.2
> 
> On Wed, Feb 1, 2012 at 1:55 PM,   wrote:
> > +SRC_URI += " file://connector-msg-size-fix.patch"
> 
> I happen to peek into this patch. It seems this patch should not be
> applied
> since its specific to a wrs kernel and linux-yocto does not apply this
> patch
> as well.
> 

This commit can also be kept out for now.

Nitin


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

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

Re: [OE-core] [patch-v2 1/7] byacc: upggrade from 20111219 to 20120115

[Kamble, Nitin A]

Thanks for catching the typo. I have corrected it in the branch.
Nitin


> -Original Message-
> From: Paul Menzel [mailto:paulepan...@users.sourceforge.net]
> Sent: Thursday, February 02, 2012 12:33 AM
> To: openembedded-core@lists.openembedded.org
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [patch-v2 1/7] byacc: upggrade from 20111219 to
> 20120115
> 
> Dear Nitin,
> 
> 
> Am Mittwoch, den 01.02.2012, 15:40 -0800 schrieb
> nitin.a.kam...@intel.com:
> > From: Nitin A Kamble 
> 
> there is a typo in the summary. Please fix »upgrade« in your branch.
> There is no need to resend the patch it.
> 
> > update md5sum for license as the copyright years are updated in the
> > file
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../byacc/{byacc_20111219.bb => byacc_20120115.bb} |6 +++---
> >  1 files changed, 3 insertions(+), 3 deletions(-)  rename
> > meta/recipes-extended/byacc/{byacc_20111219.bb => byacc_20120115.bb}
> > (59%)
> 
> […]
> 
> Reviewed-by: Paul Menzel 
> 
> 
> Thanks,
> 
> Paul
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 8/8] gcc: enable multilib for target gcc

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> McClintock Matthew-B29882
> Sent: Wednesday, March 14, 2012 7:43 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 8/8] gcc: enable multilib for target gcc
> 
> On Wed, Mar 14, 2012 at 9:02 PM,   wrote:
> >   ${libdir}/${TARGET_SYS}/${BINV}/crt* \
> > +  ${libdir}/${TARGET_SYS}/${BINV}/32 \
> > +  ${libdir}/${TARGET_SYS}/${BINV}/x32 \
> > +  ${libdir}/${TARGET_SYS}/${BINV}/n32 \
> 
> Would ${libdir}/${TARGET_SYS}/${BINV}/64 ever exist?
> 
> -M

It will exist. Thanks for catching this.

Nitin

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

Re: [OE-core] [PATCH 5/8] python: fix install when libdir is not "lib"

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Andreas Oberritter
> Sent: Wednesday, March 14, 2012 8:00 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 5/8] python: fix install when libdir is
> not "lib"
> 
> Hello Nitin,
> 
> On 15.03.2012 03:02, nitin.a.kam...@intel.com wrote:
> > --- a/meta/recipes-devtools/python/python_2.7.2.bb
> > +++ b/meta/recipes-devtools/python/python_2.7.2.bb
> > @@ -20,7 +20,7 @@ SRC_URI += "\
> >file://setup_py_skip_cross_import_check.patch \
> >file://add-md5module-support.patch \
> >file://host_include_contamination.patch \
> > -  file://sys_platform_is_now_always_linux2.patch \
> 
> did you remove this one by accident?
> 
> Regards,
> Andreas
> 
Andreas,
Yes, it was an accident. I will correct it. Thanks for catching.

Nitin

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

Re: [OE-core] [PATCH 7/8] gcc: remove the 64bithack patch

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Thursday, March 15, 2012 1:31 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 7/8] gcc: remove the 64bithack patch
> 
> On Wed, 2012-03-14 at 19:02 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > and bump PR
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/recipes-devtools/gcc/gcc-4.6.inc |1 -
> >  meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch |   68 ---
> --
> >  2 files changed, 0 insertions(+), 69 deletions(-)
> >  delete mode 100644 meta/recipes-devtools/gcc/gcc-4.6/64bithack.patch
> 
> 
> As far as I can tell whilst this will make multilib work on the target
> device, since you've removed this patch, the actual -cross toolchains
> used for multilib builds will be broken since they may or may not look
> in the correct libdir?
> 
> Cheers,
> 
> Richard
> 

Hi Richard,
  This is not an issue. do_gcc_multilib_setup() is always configuring the gcc 
multilib files. For cross gcc recipes it is only using DEFAULTTUNE while for 
target it is using DEFAULTTUNE & MULTILIB_VARIENTS. Also in my testing cross 
gcc recipes did not have any such issues.

Thanks,
Nitin


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

Re: [OE-core] [PATCH 5/8] python: fix install when libdir is not "lib"

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Thursday, March 15, 2012 12:19 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 5/8] python: fix install when libdir is
> not "lib"
> 
> On Wed, Mar 14, 2012 at 07:02:14PM -0700, nitin.a.kam...@intel.com
> wrote:
> > From: Nitin A Kamble 
> >
> > This commit fixes python's install issue of not finding the native
> > pythong binray modules.
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../python/fix_for_using_different_libdir.patch|   78
> 
> >  meta/recipes-devtools/python/python_2.7.2.bb   |3 +-
> >  2 files changed, 80 insertions(+), 1 deletions(-)  create mode
> 100644
> > meta/recipes-
> devtools/python/python/fix_for_using_different_libdir.pat
> > ch
> >
> > diff --git a/meta/recipes-devtools/python/python_2.7.2.bb
> > b/meta/recipes-devtools/python/python_2.7.2.bb
> > index d2100be..412b294 100644
> > --- a/meta/recipes-devtools/python/python_2.7.2.bb
> > +++ b/meta/recipes-devtools/python/python_2.7.2.bb
> > @@ -20,7 +20,7 @@ SRC_URI += "\
> >file://setup_py_skip_cross_import_check.patch \
> >file://add-md5module-support.patch \
> >file://host_include_contamination.patch \
> > -  file://sys_platform_is_now_always_linux2.patch \
> > +  file://fix_for_using_different_libdir.patch \
> 
> ^ really?

Martin,
Removing a patch was an accident. It is getting fixed now. Thanks for catching 
it.

Nitin

> 
> >  "
> >
> >  S = "${WORKDIR}/Python-${PV}"
> > @@ -99,6 +99,7 @@ do_install() {
> >
> > oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/pgen \
> > HOSTPYTHON=${STAGING_BINDIR_NATIVE}/python \
> > +
> > +CROSSPYTHONPATH=${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-
> d
> > +ynload/ \
> > STAGING_LIBDIR=${STAGING_LIBDIR} \
> > STAGING_INCDIR=${STAGING_INCDIR} \
> > BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
> 
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

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

Re: [OE-core] [PATCH 1/1] image-types: add btrfs as a supported fstype

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Anders Darander
> Sent: Wednesday, September 07, 2011 12:16 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1] image-types: add btrfs as a
> supported fstype
> 
> * nitin.a.kam...@intel.com  [110906 23:07]:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/classes/image_types.bbclass |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> > index c24b326..3e303ed 100644
> > --- a/meta/classes/image_types.bbclass
> > +++ b/meta/classes/image_types.bbclass
> > @@ -141,4 +141,4 @@ IMAGE_DEPENDS_ubi = "mtd-utils-native"
> >  IMAGE_DEPENDS_ubifs = "mtd-utils-native"
> >
> >  # This variable is available to request which values are suitable
> for IMAGE_FSTYPES
> > -IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz live squashfs
> squashfs-lzma ubi tar tar.gz tar.bz2 tar.xz cpio cpio.gz cpio.xz
> cpio.lzma"
> > +IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz btrfs live
> squashfs squashfs-lzma ubi tar tar.gz tar.bz2 tar.xz cpio cpio.gz
> cpio.xz cpio.lzma"
> 
> As Joshua already replied, this isn't enough.
> This raises one question, though. Have you successfully built
> btrfs-image? If so, I assume that you have more patches locally,
> otherwise you should resist submitting patches, unless they're clearly
> marked as RFC (request for comments, and thus not to be applied).
> 
> Cheers,
> Anders

All these pieces Josh mentioned are already in the tree. I found this new line, 
and saw btrfs was not listed in it so added there also. The btrfs support in 
yocto is working with Linux-yocto 3.x kernel. The btrfs kernel config needs to 
be enabled, I have sent a patch for that implementing it as a kernel feature, 
Once that is there then also need to enable the btrfs feature in the 
Linux-yocto kernel recipe. I will send a patch for that too. 

Thanks,
Nitin


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

Re: [OE-core] [PATCH 1/1] image-types: add btrfs as a supported fstype

[Kamble, Nitin A]

> 
> My apologies.
> You're correct in that the pieces mentioned by Josh is already in the
> tree.
> 
> However, the commit log should probably have included something like
> "enabling btrfs support for hob", perhaps worded slightly better.

Makes sense. I was not aware of that line is there for hob, now I know it, and 
change the commit log.
Nitin

> 
> Cheers,
> Anders
> 

> --
> Anders Darander
> ChargeStorm AB
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 4/4] python, python-native: upgrade from 2.6.6 to 2.7.2

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Friday, September 30, 2011 11:38 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 4/4] python, python-native: upgrade from
> 2.6.6 to 2.7.2
> 
> On Thu, Sep 29, 2011 at 06:27:11PM -0700, nitin.a.kam...@intel.com
> wrote:
> > From: Nitin A Kamble 
> >
> > rename from meta/recipes-devtools/python/python-2.6-manifest.inc
> > rename to meta/recipes-devtools/python/python-2.7-manifest.inc
> 
> this is wrong.. just to rename it isn't enough
> 
> I will send patch which regenerates manifest with right paths to
> actually package something..
> 
> Regards,

Hi Martin,
  Thanks for catching this. I did not see issue with old manifest. But getting 
new manifest would be better.
Thanks,
Nitin


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

Re: [OE-core] [PATCH 4/4] python, python-native: upgrade from 2.6.6 to 2.7.2

[Kamble, Nitin A]

Hi Martin,
 Ok, I will reproduce it with your manifest patch and look into fixing it.

Thanks & Regards,
Nitin


> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Saturday, October 01, 2011 11:34 AM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCH 4/4] python, python-native: upgrade from
> 2.6.6 to 2.7.2
> 
> On Fri, Sep 30, 2011 at 8:46 PM, Martin Jansa 
> wrote:
> > On Fri, Sep 30, 2011 at 11:40:47AM -0700, Kamble, Nitin A wrote:
> >>
> >> > -Original Message-
> >> > From: openembedded-core-boun...@lists.openembedded.org
> >> > [mailto:openembedded-core-boun...@lists.openembedded.org] On
> Behalf Of
> >> > Martin Jansa
> >> > Sent: Friday, September 30, 2011 11:38 AM
> >> > To: Patches and discussions about the oe-core layer
> >> > Subject: Re: [OE-core] [PATCH 4/4] python, python-native: upgrade
> from
> >> > 2.6.6 to 2.7.2
> >> >
> >> > On Thu, Sep 29, 2011 at 06:27:11PM -0700, nitin.a.kam...@intel.com
> >> > wrote:
> >> > > From: Nitin A Kamble 
> >> > >
> >> > > rename from meta/recipes-devtools/python/python-2.6-manifest.inc
> >> > > rename to meta/recipes-devtools/python/python-2.7-manifest.inc
> >> >
> >> > this is wrong.. just to rename it isn't enough
> >> >
> >> > I will send patch which regenerates manifest with right paths to
> >> > actually package something..
> >> >
> >> > Regards,
> >>
> >> Hi Martin,
> >>   Thanks for catching this. I did not see issue with old manifest.
> But getting new manifest would be better.
> >
> > Maybe you had python2.6 packages still arround, but for me the issue
> > looked like this (because almost all python-* packages were skipped
> as
> > empty)
> > -FILES_${PN}-foo="${libdir}/python2.6/foo"
> > +FILES_${PN}-foo="${libdir}/python2.7/foo"
> >
> >
> > | Collected errors:
> > |  * satisfy_dependencies_for: Cannot satisfy the following
> dependencies
> > for task-shr-minimal-fso:
> > |  *    python-textutils *      python-multiprocessing *
> > python-shell *  python-syslog *         python-threading *
> > python-xml *    python-io *  python-logging *         python-
> stringold *
> > python-ctypes *         python-difflib *        python-datetime *
> > python-logging *        python-textutils *    python-sqlite3 *
> > python-subprocess *     python-io *     python-fcntl *  python-
> stringold
> > *      python-pprint *         python-shell *  python-datetime *
> > *      python-codecs *
> > |  * opkg_install_cmd: Cannot install package task-shr-minimal-fso.
> > |  * satisfy_dependencies_for: Cannot satisfy the following
> dependencies
> > for task-shr-minimal-gtk:
> > |  *    libpoppler5 (>= 0.12.3) *       libpoppler5 (>= 0.12.3) *
> > libpoppler5 (>= 0.12.3) *
> > |  * opkg_install_cmd: Cannot install package task-shr-minimal-gtk.
> > |  * satisfy_dependencies_for: Cannot satisfy the following
> dependencies
> > for task-shr-minimal-apps:
> > |  *    python-resource *       python-io *     python-terminal *
> > python-fcntl *  python-shell *  python-lang *   python-lang *
> > python-lang *   python-lang *         python-codecs *
> > python-lang *   libpoppler5 (>= 0.12.3) *
> > |  * opkg_install_cmd: Cannot install package task-shr-minimal-apps.
> > |  * satisfy_dependencies_for: Cannot satisfy the following
> dependencies
> > for task-shr-cli:
> > |  *    python-compression *    python-netclient *      python-
> textutils
> > *      python-image *  python-mime *   python-json *   python-html *
> > *      python-sqlite3 *      python-netclient *      python-sqlite3 *
> > *      python-netclient *
> > |  * opkg_install_cmd: Cannot install package task-shr-cli.
> > | ERROR: Function 'do_rootfs' failed (see
> > /OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/shr-image-2.0-
> r18/temp/log.do_rootfs.13435
> > for further information)
> > NOTE: package shr-image-2.0-r18: task do_rootfs: Failed
> > ERROR: Task 8
> > (/OE/shr-core/meta-smartphone/meta-shr/recipes-shr/images/shr-
> image.bb,
> > do_rootfs) failed with exit code '1'
> > ERROR:
> > '/OE/shr-core/meta-smartphone/meta-shr/recipes-shr/images/shr-
> image.bb'
> > failed
> 
> Even with right manifest few modules which were built fine before are
> failing

Re: [OE-core] gdb-cross-canadian fails to build

[Kamble, Nitin A]

> -Original Message-
> From: otavio.salva...@gmail.com [mailto:otavio.salva...@gmail.com] On
> Behalf Of Otavio Salvador
> Sent: Tuesday, October 04, 2011 1:48 PM
> To: Patches and discussions about the oe-core layer; Kamble, Nitin A
> Subject: Re: gdb-cross-canadian fails to build
> 
> On Tue, Oct 4, 2011 at 17:40, Otavio Salvador 
> wrote:
> ...
> > Log data follows:
> > | NOTE: Applying patch 'no-werror.patch'
> > (openembedded-core/meta/recipes-devtools/gdb/gdb/no-werror.patch)
> ...
> > /home/otavio/hacking/ossystems/embedded-linux/openembedded-
> core/meta/recipes-devtools/gdb/gdb-cross-canadian_7.3.1.bb:
> ...
> 
> It seems to have been broken by:
> 9002f664383d71682767546524e1299137b6fe4f
> 
> Nitin, can you take a look?
Sure, I will look into it.

Thanks,
Nitin


> 
> --
> Otavio Salvador                             O.S. Systems
> E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

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

Re: [OE-core] [PATCH 4/4] python, python-native: upgrade from 2.6.6 to 2.7.2

[Kamble, Nitin A]

Martin,
  I am fixing the python 2.7.2 recipe, and I need to update the 
generate-manifest-2.7.py script slightly, to get more files included in the 
python-core package.

BTW how to run this script ? some documentation of it in the script would be 
useful.

Thanks,
Nitin


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

Re: [OE-core] [PATCH 4/4] python, python-native: upgrade from 2.6.6 to 2.7.2

[Kamble, Nitin A]

> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Thursday, October 13, 2011 2:41 PM
> To: Kamble, Nitin A
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 4/4] python, python-native: upgrade from
> 2.6.6 to 2.7.2
> 
> On Thu, Oct 13, 2011 at 01:09:15PM -0700, Kamble, Nitin A wrote:
> > Martin,
> >   I am fixing the python 2.7.2 recipe, and I need to update the
> generate-manifest-2.7.py script slightly, to get more files included in
> the python-core package.
> 
> great, I was debuging it a bit more today and found out that the
> problem seems to be in python-native, because with python-native-2.7.2
> when I try to build old python-2.6.6 it's also tring to link extra
> modules to -native libpython2.7 and fails:
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so: file
> not recognized: File format not recognized
> 
> but even after comparing sysroots/builddirs/logs from 2.6.6 and 2.7.2 I
> still don't see why it picked right libpython2.6 before and now it
> fails.
> I've tried it without multilib support and partially reverted changes
> in patches from 2.6.6 and still it fails :/
> 
> btw: there seems to be also issue in runtime SHR root@gjama ~ $ python
> -v Could not find platform independent libraries  Consider
> setting $PYTHONHOME to [:] # installing zipimport
> hook import zipimport # builtin # installed zipimport hook
> ImportError: No module named site
> # clear __builtin__._
> # clear sys.path
> # clear sys.argv
> # clear sys.ps1
> # clear sys.ps2
> # clear sys.exitfunc
> # clear sys.exc_type
> # clear sys.exc_value
> # clear sys.exc_traceback
> # clear sys.last_type
> # clear sys.last_value
> # clear sys.last_traceback
> # clear sys.path_hooks
> # clear sys.path_importer_cache
> # clear sys.meta_path
> # clear sys.flags
> # clear sys.float_info
> # restore sys.stdin
> # restore sys.stdout
> # restore sys.stderr
> # cleanup __main__
> # cleanup[1] zipimport
> # cleanup[1] signal
> # cleanup[1] exceptions
> # cleanup[1] _warnings
> # cleanup sys
> # cleanup __builtin__
> # cleanup ints: 5 unfreed ints
> # cleanup floats
> 
> > BTW how to run this script ? some documentation of it in the script
> would be useful.

I got python 2.7.2 to work inside the qemux86 machine now. I will send a pull 
request for review/test today.

Thanks,
Nitin


> 
> just execute it and it prints manifest, so something like this:
> openembedded-core $ scripts/contrib/python/generate-manifest-2.7.py >
> meta/recipes-devtools/python/python-2.7-manifest.inc
> 
> Regards,
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

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

Re: [OE-core] [review/test 0/5] Python upgrade and other commits

[Kamble, Nitin A]

I also tested on qemuppc and python's basic functionality is working inside 
qemuppc machine.

Thanks,
Nitin


> -Original Message-
> From: Kamble, Nitin A
> Sent: Thursday, October 13, 2011 4:06 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Kamble, Nitin A; Martin Jansa
> Subject: [review/test 0/5] Python upgrade and other commits
> 
> From: Nitin A Kamble 
> 
> I tested and found that python 2.7.2 is working as expected inside
> qemux86 machine.
> Please give it a try and let me know your experience.
> 
> Thanks,
> Nitin
> 
> The following changes since commit
> 5ed59ae0f25bf673d514df2371da7e0415b62bb2:
> 
>   local.conf.sample: Disable interactive patch resolution for now since
> doesn't work well (2011-10-07 00:00:21 +0100)
> 
> are available in the git repository at:
>   git://git.pokylinux.org/poky-contrib nitin/upgrades
>   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/upgrades
> 
> Martin Jansa (1):
>   python: update generate-manifest for 2.7 version and regenerate it
> 
> Nitin A Kamble (4):
>   x86 tune files: set baselib for x32 tune as libx32
>   python-dbus: upgrade from 0.83.2 to 0.84.0
>   python, python-native: upgrade from 2.6.6 to 2.7.2
>   update python 2.7 manifest
> 
>  meta/conf/distro/include/default-versions.inc  |6 +-
>  meta/conf/machine/include/ia32/arch-ia32.inc   |2 +-
>  meta/conf/machine/include/tune-core2.inc   |2 +-
>  ...on-2.6-manifest.inc => python-2.7-manifest.inc} |  124 +-
>  ...python-dbus_0.83.2.bb => python-dbus_0.84.0.bb} |4 +-
>  .../python/python-native/multilib.patch|  240
> 
>  .../python/python-native/nohostlibs.patch  |   36 ++-
>  ...thon-native_2.6.6.bb => python-native_2.7.2.bb} |   13 +-
>  meta/recipes-devtools/python/python.inc|   16 +-
>  .../01-use-proper-tools-for-cross-build.patch  |   80 ---
>  .../python/python/02-remove-test-for-cross.patch   |  108 -
>  .../06-avoid_usr_lib_termcap_path_in_linking.patch |   12 +-
>  .../python/06-ctypes-libffi-fix-configure.patch|   42 ++---
>  meta/recipes-devtools/python/python/multilib.patch |  126 ++-
>  .../python/python/security_issue_2254_fix.patch|  184 
> ---
>  .../python/{python_2.6.6.bb => python_2.7.2.bb}|   11 +-
>  meta/site/common-linux |3 +
>  ...te-manifest-2.6.py => generate-manifest-2.7.py} |6 +-
>  18 files changed, 495 insertions(+), 520 deletions(-)
>  rename meta/recipes-devtools/python/{python-2.6-manifest.inc =>
> python-2.7-manifest.inc} (52%)
>  rename meta/recipes-devtools/python/{python-dbus_0.83.2.bb => python-
> dbus_0.84.0.bb} (83%)
>  create mode 100644 meta/recipes-devtools/python/python-
> native/multilib.patch
>  rename meta/recipes-devtools/python/{python-native_2.6.6.bb => python-
> native_2.7.2.bb} (74%)
>  delete mode 100644 meta/recipes-devtools/python/python/02-remove-test-
> for-cross.patch
>  delete mode 100644 meta/recipes-
> devtools/python/python/security_issue_2254_fix.patch
>  rename meta/recipes-devtools/python/{python_2.6.6.bb =>
> python_2.7.2.bb} (92%)
>  rename scripts/contrib/python/{generate-manifest-2.6.py => generate-
> manifest-2.7.py} (99%)
> 
> --
> 1.7.4.4


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

Re: [OE-core] [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Friday, October 14, 2011 2:12 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [review/test 3/5] python, python-native: upgrade
> from 2.6.6 to 2.7.2
> 
> On Fri, Oct 14, 2011 at 10:19:39AM +0200, Martin Jansa wrote:
> > On Thu, Oct 13, 2011 at 04:06:13PM -0700, nitin.a.kam...@intel.com
> wrote:
> > > From: Nitin A Kamble 
> > >
> >
> > This patch does not apply after
> > 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17
> >
> > can you rebase on top of oe-core?
Ok, I will do the rebase and send new commits. I was getting into some 
unrelated issues with the top of the oecore, hence I was using the 1.1 edison 
branch to do this work.

> >
> > Also please drop
> > DEFAULT_PREFERENCE = "-27"

Done in my branch.

> >
> > we have only one python version so I guess it's not usefull at all
> > anymore
> >
> > I'll apply it manually, test it here.. and report if those modules
> are
> > build later..
> 
> seems the same as with previous version..
> 
> log.do_compile full of
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so: file
> not recognized: File format not recognized
> collect2: ld returned 1 exit status

I am not seeing this error.

> 
> and only built module is sqlite
> OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.0 $ ls
> Python-2.7.2/build/lib.linux-x86_64-2.7/
> _sqlite3.so
> 
> while with 2.6 we had a lot of modules
> $ ls Python-2.6.6/build/lib.linux-x86_64-2.6/
> _bisect.so  _codecs_jp.so_ctypes.so_fileio.so
> _json.so _random.so   _testcapi.so  bz2.so
> datetime.so itertools.so  parser.sospwd.so
> unicodedata.so
> _bytesio.so _codecs_kr.so_ctypes_test.so   _functools.so
> _locale.so   _socket.so   _weakref.so   cPickle.sofcntl.so
> math.so   pyexpat.so   strop.sozlib.so
> _codecs_cn.so   _codecs_tw.so_curses.so_hashlib.so
> _lsprof.so   _sqlite3.so  array.so  cStringIO.so
> future_builtins.so  mmap.so   readline.so  syslog.so
> _codecs_hk.so   _collections.so  _curses_panel.so  _heapq.so
> _multibytecodec.so   _ssl.so  audioop.socmath.so  gdbm.so
> nis.soresource.so  termios.so
> _codecs_iso2022.so  _csv.so  _elementtree.so   _hotshot.so
> _multiprocessing.so  _struct.so   binascii.so   crypt.so  grp.so
> operator.so   select.sotime.so

I am seeing these .so modules built:
$ find image/ | grep "\.so"
image/usr/lib/python2.7/lib-dynload/_codecs_tw.so
image/usr/lib/python2.7/lib-dynload/mmap.so
image/usr/lib/python2.7/lib-dynload/resource.so
image/usr/lib/python2.7/lib-dynload/_random.so
image/usr/lib/python2.7/lib-dynload/termios.so
image/usr/lib/python2.7/lib-dynload/_codecs_jp.so
image/usr/lib/python2.7/lib-dynload/strop.so
image/usr/lib/python2.7/lib-dynload/_io.so
image/usr/lib/python2.7/lib-dynload/syslog.so
image/usr/lib/python2.7/lib-dynload/_codecs_hk.so
image/usr/lib/python2.7/lib-dynload/_testcapi.so
image/usr/lib/python2.7/lib-dynload/_collections.so
image/usr/lib/python2.7/lib-dynload/_socket.so
image/usr/lib/python2.7/lib-dynload/future_builtins.so
image/usr/lib/python2.7/lib-dynload/_csv.so
image/usr/lib/python2.7/lib-dynload/operator.so
image/usr/lib/python2.7/lib-dynload/parser.so
image/usr/lib/python2.7/lib-dynload/crypt.so
image/usr/lib/python2.7/lib-dynload/_elementtree.so
image/usr/lib/python2.7/lib-dynload/nis.so
image/usr/lib/python2.7/lib-dynload/_lsprof.so
image/usr/lib/python2.7/lib-dynload/_multiprocessing.so
image/usr/lib/python2.7/lib-dynload/_codecs_kr.so
image/usr/lib/python2.7/lib-dynload/cmath.so
image/usr/lib/python2.7/lib-dynload/_multibytecodec.so
image/usr/lib/python2.7/lib-dynload/array.so
image/usr/lib/python2.7/lib-dynload/bz2.so
image/usr/lib/python2.7/lib-dynload/_codecs_cn.so
image/usr/lib/python2.7/lib-dynload/_ssl.so
image/usr/lib/python2.7/lib-dynload/cStringIO.so
image/usr/lib/python2.7/lib-dynload/_json.so
image/usr/lib/python2.7/lib-dynload/_ctypes_test.so
image/usr/lib/python2.7/lib-dynload/_struct.so
image/usr/lib/python2.7/lib-dynload/itertools.so
image/usr/lib/python2.7/lib-dynload/zlib.so
image/usr/lib/python2.7/lib-dynload/spwd.so
image/usr/lib/python2.7/lib-dynload/_codecs_iso2022.so
image/usr/lib/python2.7/lib-dynload/audioop.so
image/usr/lib/python2.7/lib-dynload/math.so
image/usr/lib/python2.7/lib-dynload/ossaudiodev.so
image/usr/lib/python2.7/lib-dynload/_bisect.so
image/usr/lib/python2.7/lib-dynload/_hotshot.so
image/usr/lib/python2.7/lib-dynload/_curses.so
image/usr/lib/python2.7/lib-dynload/select.so
image/usr/lib/python2.7/lib-dynload/linuxaudiodev.so
image/usr/lib/python2.7/lib-dynload/time.so
image/usr/lib/python2.7/lib-dynload/pyexpat.so
image/usr/lib/python2.7/lib-dynload/cPickle.so
image/usr/lib/python2.7/lib-dynload/fcntl.so
image/usr/lib/python2.7/

Re: [OE-core] [PATCH 2/5] gmp: also generate the libgmpcxx library

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Tuesday, October 18, 2011 1:54 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 2/5] gmp: also generate the libgmpcxx
> library
> 
> On (18/10/11 13:14), nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/recipes-support/gmp/gmp.inc  |2 ++
> >  meta/recipes-support/gmp/gmp_4.2.1.bb |2 +-
> >  meta/recipes-support/gmp/gmp_5.0.2.bb |2 +-
> >  3 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes-
> support/gmp/gmp.inc
> > index 66349e6..77ce10d 100644
> > --- a/meta/recipes-support/gmp/gmp.inc
> > +++ b/meta/recipes-support/gmp/gmp.inc
> > @@ -14,3 +14,5 @@ ARM_INSTRUCTION_SET = "arm"
> >  acpaths = ""
> >
> >  BBCLASSEXTEND = "native nativesdk"
> > +
> > +EXTRA_OECONF += " --enable-cxx=yes"
> 
> if you want 'yes' then just --enable-cxx is enough have you tried with
> --enable-cxx=detect that would make sure that C++ compiler and runtime
> is ok. Secondly is this option needed for native recipes too ?

Thanks Khem for your comments. This option is also needed for native recipe to 
avoid having gmp-devel installed on the build system. "--enable-cxx=detect" can 
be used, but I am not sure if it is the best way yet, I think we always have 
c++ as part of gcc, not having c++ is not a case to worry. And if "detect" 
tests if c++ & runtime are not working as expected, then it should not disable 
the enable-cxx option with that reason; better would be to get a recipe build 
failure. So I still favor keeping the option as "--enable-cxx" until I can see 
the merit of "detect".

Thanks,
Nitin

> 
> > diff --git a/meta/recipes-support/gmp/gmp_4.2.1.bb b/meta/recipes-
> support/gmp/gmp_4.2.1.bb
> > index 74da6b8..97ac4b2 100644
> > --- a/meta/recipes-support/gmp/gmp_4.2.1.bb
> > +++ b/meta/recipes-support/gmp/gmp_4.2.1.bb
> > @@ -6,7 +6,7 @@ LICENSE = "LGPLv2.1+"
> >  LIC_FILES_CHKSUM =
> "file://COPYING;md5=892f569a555ba9c07a568a7c0c4fa63a \
> >
> file://COPYING.LIB;md5=fbc093901857fcd118f065f900982c24 \
> >  file://gmp-
> h.in;startline=6;endline=21;md5=5e25ffd16996faba8c1cd27b04b16099"
> > -PR = "r0"
> > +PR = "r1"
> >
> >  SRC_URI = "${GNU_MIRROR}/gmp/${BP}.tar.bz2 \
> > file://disable-stdc.patch"
> > diff --git a/meta/recipes-support/gmp/gmp_5.0.2.bb b/meta/recipes-
> support/gmp/gmp_5.0.2.bb
> > index 03fef45..f80971e 100644
> > --- a/meta/recipes-support/gmp/gmp_5.0.2.bb
> > +++ b/meta/recipes-support/gmp/gmp_5.0.2.bb
> > @@ -2,7 +2,7 @@ require gmp.inc
> >  LICENSE="LGPLv3&GPLv3"
> >  LIC_FILES_CHKSUM =
> "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
> >
> file://version.c;endline=18;md5=d8c56b52b9092346b9f93b4da65ef790"
> > -PR = "r0"
> > +PR = "r1"
> >
> >  SRC_URI_append += "file://sh4-asmfix.patch \
> > file://use-includedir.patch "
> > --
> > 1.7.4.4
> >
> >
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> --
> -Khem
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 3/5] python-scons: upgrade from 2.0.1 to 2.1.0

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Tuesday, October 18, 2011 1:54 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 3/5] python-scons: upgrade from 2.0.1 to
> 2.1.0
> 
> On (18/10/11 13:15), nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  ...ative_2.0.1.bb => python-scons-native_2.1.0.bb} |3 +--
> >  ...python-scons_2.0.1.bb => python-scons_2.1.0.bb} |6 +++---
> >  2 files changed, 4 insertions(+), 5 deletions(-)
> >  rename meta/recipes-devtools/python/{python-scons-native_2.0.1.bb =>
> python-scons-native_2.1.0.bb} (89%)
> >  rename meta/recipes-devtools/python/{python-scons_2.0.1.bb =>
> python-scons_2.1.0.bb} (51%)
> >
> > diff --git a/meta/recipes-devtools/python/python-scons-
> native_2.0.1.bb b/meta/recipes-devtools/python/python-scons-
> native_2.1.0.bb
> > similarity index 89%
> > rename from meta/recipes-devtools/python/python-scons-native_2.0.1.bb
> > rename to meta/recipes-devtools/python/python-scons-native_2.1.0.bb
> > index f7646a2..083ad15 100644
> > --- a/meta/recipes-devtools/python/python-scons-native_2.0.1.bb
> > +++ b/meta/recipes-devtools/python/python-scons-native_2.1.0.bb
> > @@ -2,5 +2,4 @@ require python-scons_${PV}.bb
> >  inherit native
> >  DEPENDS = "python-native"
> >  RDEPENDS_${PN} = ""
> > -PR = "r1"
> > -
> > +PR = "r0"
> > diff --git a/meta/recipes-devtools/python/python-scons_2.0.1.bb
> b/meta/recipes-devtools/python/python-scons_2.1.0.bb
> > similarity index 51%
> > rename from meta/recipes-devtools/python/python-scons_2.0.1.bb
> > rename to meta/recipes-devtools/python/python-scons_2.1.0.bb
> > index 1c7939e..22df333 100644
> > --- a/meta/recipes-devtools/python/python-scons_2.0.1.bb
> > +++ b/meta/recipes-devtools/python/python-scons_2.1.0.bb
> > @@ -1,15 +1,15 @@
> >  DESCRIPTION = "A Software Construction Tool"
> >  SECTION = "devel/python"
> >  LICENSE = "MIT"
> > -LIC_FILES_CHKSUM =
> "file://LICENSE.txt;md5=8481211ebbeaed9cdc7ad5a3b0c98aaf"
> > +LIC_FILES_CHKSUM =
> "file://LICENSE.txt;md5=ab8b65435c2e520ed18e67459f1f9bb9"
> 
> a little commentary on what changed in license text would be nice here

The change is copyright year to 2011 :)
Nitin

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

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

Re: [OE-core] [PATCH 2/5] gmp: also generate the libgmpcxx library

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Tuesday, October 18, 2011 2:14 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 2/5] gmp: also generate the libgmpcxx
> library
> 
> On (18/10/11 14:06), Kamble, Nitin A wrote:
> >
> >
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> > > Khem Raj
> > > Sent: Tuesday, October 18, 2011 1:54 PM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [PATCH 2/5] gmp: also generate the libgmpcxx
> > > library
> > >
> > > On (18/10/11 13:14), nitin.a.kam...@intel.com wrote:
> > > > From: Nitin A Kamble 
> > > >
> > > > Signed-off-by: Nitin A Kamble 
> > > > ---
> > > >  meta/recipes-support/gmp/gmp.inc  |2 ++
> > > >  meta/recipes-support/gmp/gmp_4.2.1.bb |2 +-
> > > >  meta/recipes-support/gmp/gmp_5.0.2.bb |2 +-
> > > >  3 files changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes-
> > > support/gmp/gmp.inc
> > > > index 66349e6..77ce10d 100644
> > > > --- a/meta/recipes-support/gmp/gmp.inc
> > > > +++ b/meta/recipes-support/gmp/gmp.inc
> > > > @@ -14,3 +14,5 @@ ARM_INSTRUCTION_SET = "arm"
> > > >  acpaths = ""
> > > >
> > > >  BBCLASSEXTEND = "native nativesdk"
> > > > +
> > > > +EXTRA_OECONF += " --enable-cxx=yes"
> > >
> > > if you want 'yes' then just --enable-cxx is enough have you tried
> with
> > > --enable-cxx=detect that would make sure that C++ compiler and
> runtime
> > > is ok. Secondly is this option needed for native recipes too ?
> >
> > Thanks Khem for your comments. This option is also needed for native
> recipe to avoid having gmp-devel installed on the build system. "--
> enable-cxx=detect" can be used, but I am not sure if it is the best way
> yet, I think we always have c++ as part of gcc, not having c++ is not a
> case to worry. And if "detect" tests if c++ & runtime are not working
> as expected, then it should not disable the enable-cxx option with that
> reason; better would be to get a recipe build failure. So I still favor
> keeping the option as "--enable-cxx" until I can see the merit of
> "detect".
> 
> detect can make sure that compilers are working as it expects them to
> be. so likely less issues when it is used later.

Khem,
  When detect fails then configure will get an error, and will not proceed with 
disabling cxx, so that is good.

# If --enable-cxx=yes but a C++ compiler can't be found, then abort.
  if test $want_cxx = no && test $enable_cxx = yes; then
as_fn_error $? "C++ compiler not available, see config.log for details" 
"$LINENO" 5
  fi

Thanks,
Nitin


> 
> >
> > Thanks,
> > Nitin
> >
> > >
> > > > diff --git a/meta/recipes-support/gmp/gmp_4.2.1.bb
> b/meta/recipes-
> > > support/gmp/gmp_4.2.1.bb
> > > > index 74da6b8..97ac4b2 100644
> > > > --- a/meta/recipes-support/gmp/gmp_4.2.1.bb
> > > > +++ b/meta/recipes-support/gmp/gmp_4.2.1.bb
> > > > @@ -6,7 +6,7 @@ LICENSE = "LGPLv2.1+"
> > > >  LIC_FILES_CHKSUM =
> > > "file://COPYING;md5=892f569a555ba9c07a568a7c0c4fa63a \
> > > >
> > > file://COPYING.LIB;md5=fbc093901857fcd118f065f900982c24 \
> > > >  file://gmp-
> > > h.in;startline=6;endline=21;md5=5e25ffd16996faba8c1cd27b04b16099"
> > > > -PR = "r0"
> > > > +PR = "r1"
> > > >
> > > >  SRC_URI = "${GNU_MIRROR}/gmp/${BP}.tar.bz2 \
> > > > file://disable-stdc.patch"
> > > > diff --git a/meta/recipes-support/gmp/gmp_5.0.2.bb
> b/meta/recipes-
> > > support/gmp/gmp_5.0.2.bb
> > > > index 03fef45..f80971e 100644
> > > > --- a/meta/recipes-support/gmp/gmp_5.0.2.bb
> > > > +++ b/meta/recipes-support/gmp/gmp_5.0.2.bb
> > > > @@ -2,7 +2,7 @@ require gmp.inc
> > > >  LICENSE="LGPLv3&GPLv3"
> > > >  LIC_FILES_CHKSUM =
> > >

Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

[Kamble, Nitin A]

Koen,
   Why do you ask ?

Nitin

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Wednesday, October 19, 2011 1:31 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
> update data for some toolchain recipes
> 
> btrfs-tools is a toolchain recipe?!?!?!
> 
> 
> 
> Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:
> 
> > From: Nitin A Kamble 
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> > .../conf/distro/include/distro_tracking_fields.inc |   42
> 
> > 1 files changed, 25 insertions(+), 17 deletions(-)
> >
> > diff --git a/meta/conf/distro/include/distro_tracking_fields.inc
> b/meta/conf/distro/include/distro_tracking_fields.inc
> > index abc2cbf..e68bbe1 100644
> > --- a/meta/conf/distro/include/distro_tracking_fields.inc
> > +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> > @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" # all
> local code
> > RECIPE_LATEST_VERSION_pn-postinsts="1.0"
> > RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
> "
> >
> > -RECIPE_STATUS_pn-nasm="green"
> > +RECIPE_STATUS_pn-nasm="green"
> > RECIPE_LATEST_VERSION_pn-nasm="2.07"
> > -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
> > +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
> > RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble
> "
> >
> > +RECIPE_STATUS_pn-btrfs-tools="green"
> > +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
> > +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
> > +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> "
> > +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> progs"
> > +
> > RECIPE_STATUS_pn-perl="red" # upgrade needed
> > RECIPE_LATEST_VERSION_pn-perl="5.12.1"
> > RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
> > @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
> prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
> > RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
> > RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
> "
> >
> > -RECIPE_STATUS_pn-python-dbus="red"
> > -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
> > -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
> > +RECIPE_STATUS_pn-python-dbus="green"
> > +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
> > +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
> > RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble
> "
> > DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
> dbus Mandriva=python-dbus"
> >
> > @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
> Kamble "
> > DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
> Ubuntu=python-pyrex"
> >
> > RECIPE_STATUS_pn-python-scons="green"
> > -RECIPE_LATEST_VERSION_pn-python-scons="2.0.1"
> > +RECIPE_LATEST_VERSION_pn-python-scons="2.1.0"
> > +RECIPE_LAST_UPDATE_pn-python-scons = "Oct 18, 2011"
> > DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons
> Ubuntu=scons Mandriva=scons Debian=scons"
> > RECIPE_LAST_UPDATE_pn-python-scons = "Nov 8, 2010"
> > RECIPE_MAINTAINER_pn-python-scons = "Nitin A Kamble
> "
> > @@ -3087,15 +3096,16 @@ RECIPE_LATEST_VERSION_pn-unifdef="2.6.18+git"
> > RECIPE_MAINTAINER_pn-unifdef = "Nitin A Kamble
> "
> >
> > RECIPE_STATUS_pn-gnu-config="green"
> > -RECIPE_LATEST_VERSION_pn-gnu-config="0.0+git3155524"
> > +RECIPE_LATEST_VERSION_pn-gnu-config="svn"
> > DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
> > RECIPE_LAST_UPDATE_pn-gnu-config = "Jun 21, 2010"
> > -RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Jul 06, 2011"
> > +RECIPE_MANUAL_CHECK_DATE_pn-gnu-config = "Oct 18, 2011"
> > RECIPE_MAINTAINER_pn-gnu-config = "Nitin A Kamble
> "
> >
> > RECIPE_STATUS_pn-mpfr="green"
> > -RECIPE_LATEST_VERSION_pn-mpfr="3.0.0"
> > -RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Jul 06, 2011"
> > +RECIPE_LATEST_VERSION_pn-mpfr="3.0.1"
> > +RECIPE_MANUAL_CHECK_DATE_pn-mpfr = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-mpfr = "Apr 07, 2011"
> > RECIPE_MAINTAINER_pn-mpfr = "Nitin A Kamble
> "
> >
> > RECIPE_STATUS_pn-gmp="green"
> > @@ -3110,9 +3120,10 @@ RECIPE_MANUAL_CHECK_DATE_pn-libmpc = "Jan 25,
> 2011"
> > RECIPE_MAINTAINER_pn-libmpc = "Nitin A Kamble
> "
> > DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
> >
> > -RECIPE_STATUS_pn-byacc="red"
> > +RECIPE_STATUS_pn-byacc="green"
> > RECIPE_LATEST_VERSION_pn-byacc="20101229"
> > -RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Jul 06, 2011"
> > +RECIPE_MANUAL_CHECK_DATE_pn-byacc = "Oct 18, 2011"
> > +RECIPE_LAST_UPDATE_pn-byacc = "Oct 18, 2010"
> > RECIPE_MAINTAINER_pn-byacc = "Nitin A Kamble
> "
> >
> > RECIPE_STATUS_pn-libconvert-asn1-perl="green"
> > @@ -3122,8 +3133,8 @@ RECIPE_LAST_UPDATE_pn-libconvert-asn1-perl =
> "Aug 13, 2010"
> > RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Nitin A Kamble
> "
>

Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking: update data for some toolchain recipes

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Wednesday, October 19, 2011 8:52 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
> update data for some toolchain recipes
> 
> 
> Op 19 okt. 2011, om 17:49 heeft Kamble, Nitin A het volgende
> geschreven:
> 
> > Koen,
> >   Why do you ask ?
> 
> Because I want the commit message to match to commit and now it
> doesn't.
> 
It will be too many recipes to list on one line, shall I split the commit into 
multiple one for each recipe whose data is changed?

Nitin

> >
> > Nitin
> >
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of
> >> Koen Kooi
> >> Sent: Wednesday, October 19, 2011 1:31 AM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [CONSOLIDATED PULL 14/16] distro-tracking:
> >> update data for some toolchain recipes
> >>
> >> btrfs-tools is a toolchain recipe?!?!?!
> >>
> >>
> >>
> >> Op 19 okt. 2011, om 10:28 heeft Saul Wold het volgende geschreven:
> >>
> >>> From: Nitin A Kamble 
> >>>
> >>> Signed-off-by: Nitin A Kamble 
> >>> ---
> >>> .../conf/distro/include/distro_tracking_fields.inc |   42
> >> 
> >>> 1 files changed, 25 insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/meta/conf/distro/include/distro_tracking_fields.inc
> >> b/meta/conf/distro/include/distro_tracking_fields.inc
> >>> index abc2cbf..e68bbe1 100644
> >>> --- a/meta/conf/distro/include/distro_tracking_fields.inc
> >>> +++ b/meta/conf/distro/include/distro_tracking_fields.inc
> >>> @@ -3005,11 +3005,19 @@ RECIPE_STATUS_pn-run-postinsts="green" #
> all
> >> local code
> >>> RECIPE_LATEST_VERSION_pn-postinsts="1.0"
> >>> RECIPE_MAINTAINER_pn-postinsts = "Nitin A Kamble
> >> "
> >>>
> >>> -RECIPE_STATUS_pn-nasm="green"
> >>> +RECIPE_STATUS_pn-nasm="green"
> >>> RECIPE_LATEST_VERSION_pn-nasm="2.07"
> >>> -RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Jul 06, 2011"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-nasm = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-nasm = "Jun 23, 2010"
> >>> RECIPE_MAINTAINER_pn-nasm = "Nitin A Kamble
> >> "
> >>>
> >>> +RECIPE_STATUS_pn-btrfs-tools="green"
> >>> +RECIPE_LATEST_VERSION_pn-btrfs-tools="git"
> >>> +RECIPE_MANUAL_CHECK_DATE_pn-btrfs-tools = "Oct 18, 2011"
> >>> +RECIPE_LAST_UPDATE_pn-btrfs-tools = "Jun 09, 2011"
> >>> +RECIPE_MAINTAINER_pn-btrfs-tools = "Nitin A Kamble
> >> "
> >>> +DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-
> >> progs"
> >>> +
> >>> RECIPE_STATUS_pn-perl="red" # upgrade needed
> >>> RECIPE_LATEST_VERSION_pn-perl="5.12.1"
> >>> RECIPE_LAST_UPDATE_pn-perl = "May 27, 2007"
> >>> @@ -3020,9 +3028,9 @@ RECIPE_LATEST_VERSION_pn-
> >> prelink="1.0+git0+0x909470ee441237563d6236c505cb2d02ddc
> >>> RECIPE_LAST_UPDATE_pn-perl = "Jul 23, 2010"
> >>> RECIPE_MAINTAINER_pn-prelink = "Mark Hatle
> >> "
> >>>
> >>> -RECIPE_STATUS_pn-python-dbus="red"
> >>> -RECIPE_LATEST_VERSION_pn-python-dbus="0.83.1"
> >>> -RECIPE_LAST_UPDATE_pn-python-dbus = "Jul 7, 2010"
> >>> +RECIPE_STATUS_pn-python-dbus="green"
> >>> +RECIPE_LATEST_VERSION_pn-python-dbus="0.84.0"
> >>> +RECIPE_LAST_UPDATE_pn-python-dbus = "Oct 18, 2011"
> >>> RECIPE_MAINTAINER_pn-python-dbus = "Nitin A Kamble
> >> "
> >>> DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-
> >> dbus Mandriva=python-dbus"
> >>>
> >>> @@ -3062,7 +3070,8 @@ RECIPE_MAINTAINER_pn-python-pyrex = "Nitin A
> >> Kamble "
> >>> DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex
> >> Ubuntu=pyth

Re: [OE-core] [PATCH 2/6] gmp: also generate the libgmpcxx library

[Kamble, Nitin A]

> -Original Message-
> From: Saul Wold [mailto:saul.w...@intel.com]
> Sent: Thursday, October 20, 2011 12:50 AM
> To: Patches and discussions about the oe-core layer
> Cc: Kamble, Nitin A
> Subject: Re: [OE-core] [PATCH 2/6] gmp: also generate the libgmpcxx
> library
> 
> On 10/18/2011 05:30 PM, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble
> >
> > configure runs few checks to make sure c++ compiler and runtime are
> working as expected
> > with the --enable-cxx=detect option.
> >
> Somehow this change has also changed what the gmp package provides,
> before this change the package provided libgmp10 via PKG_gmp: libgmp10,
> after this change, the libgmp10 is no longer provided and causes other
> breakage.
> 
> The example case I found was a coreutils package that was built prior
> to
> this change failed to fulfill it's dependencies after this change when
> creating an image.  If I rebuild coreutils with the newer gmp build,
> then all is well, I think we need to understand this better before
> making this change.
> 
> Did something else change in the packaging that would cause use to look
> the mapping above?
> 
Saul,
  In my testing I did not get any of these issues you mentioned above. 

Also I tried to reproduce the issue with coreutils as mentioned above, and I 
can not reproduce the issue for creations of an image. Can you verify the issue 
one more time?

Thanks,
Nitin

> 
> Sau!
> 
> 
> > Signed-off-by: Nitin A Kamble
> > ---
> >   meta/recipes-support/gmp/gmp.inc  |2 ++
> >   meta/recipes-support/gmp/gmp_4.2.1.bb |2 +-
> >   meta/recipes-support/gmp/gmp_5.0.2.bb |2 +-
> >   3 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes-
> support/gmp/gmp.inc
> > index 66349e6..3c662a0 100644
> > --- a/meta/recipes-support/gmp/gmp.inc
> > +++ b/meta/recipes-support/gmp/gmp.inc
> > @@ -14,3 +14,5 @@ ARM_INSTRUCTION_SET = "arm"
> >   acpaths = ""
> >
> >   BBCLASSEXTEND = "native nativesdk"
> > +
> > +EXTRA_OECONF += " --enable-cxx=detect"
> > diff --git a/meta/recipes-support/gmp/gmp_4.2.1.bb b/meta/recipes-
> support/gmp/gmp_4.2.1.bb
> > index 74da6b8..97ac4b2 100644
> > --- a/meta/recipes-support/gmp/gmp_4.2.1.bb
> > +++ b/meta/recipes-support/gmp/gmp_4.2.1.bb
> > @@ -6,7 +6,7 @@ LICENSE = "LGPLv2.1+"
> >   LIC_FILES_CHKSUM =
> "file://COPYING;md5=892f569a555ba9c07a568a7c0c4fa63a \
> >
> file://COPYING.LIB;md5=fbc093901857fcd118f065f900982c24 \
> >   file://gmp-
> h.in;startline=6;endline=21;md5=5e25ffd16996faba8c1cd27b04b16099"
> > -PR = "r0"
> > +PR = "r1"
> >
> >   SRC_URI = "${GNU_MIRROR}/gmp/${BP}.tar.bz2 \
> >  file://disable-stdc.patch"
> > diff --git a/meta/recipes-support/gmp/gmp_5.0.2.bb b/meta/recipes-
> support/gmp/gmp_5.0.2.bb
> > index 03fef45..f80971e 100644
> > --- a/meta/recipes-support/gmp/gmp_5.0.2.bb
> > +++ b/meta/recipes-support/gmp/gmp_5.0.2.bb
> > @@ -2,7 +2,7 @@ require gmp.inc
> >   LICENSE="LGPLv3&GPLv3"
> >   LIC_FILES_CHKSUM =
> "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
> >
> file://version.c;endline=18;md5=d8c56b52b9092346b9f93b4da65ef790"
> > -PR = "r0"
> > +PR = "r1"
> >
> >   SRC_URI_append += "file://sh4-asmfix.patch \
> >  file://use-includedir.patch "


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

Re: [OE-core] [PATCH 2/6] gmp: also generate the libgmpcxx library

[Kamble, Nitin A]

> -Original Message-
> From: Saul Wold [mailto:saul.w...@intel.com]
> Sent: Friday, October 21, 2011 12:55 AM
> To: Kamble, Nitin A
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 2/6] gmp: also generate the libgmpcxx
> library
> 
> On 10/20/2011 11:04 PM, Kamble, Nitin A wrote:
> >
> >
> >> -Original Message-
> >> From: Saul Wold [mailto:saul.w...@intel.com]
> >> Sent: Thursday, October 20, 2011 12:50 AM
> >> To: Patches and discussions about the oe-core layer
> >> Cc: Kamble, Nitin A
> >> Subject: Re: [OE-core] [PATCH 2/6] gmp: also generate the libgmpcxx
> >> library
> >>
> >> On 10/18/2011 05:30 PM, nitin.a.kam...@intel.com wrote:
> >>> From: Nitin A Kamble
> >>>
> >>> configure runs few checks to make sure c++ compiler and runtime are
> >> working as expected
> >>> with the --enable-cxx=detect option.
> >>>
> >> Somehow this change has also changed what the gmp package provides,
> >> before this change the package provided libgmp10 via PKG_gmp:
> libgmp10,
> >> after this change, the libgmp10 is no longer provided and causes
> other
> >> breakage.
> >>
> >> The example case I found was a coreutils package that was built
> prior
> >> to
> >> this change failed to fulfill it's dependencies after this change
> when
> >> creating an image.  If I rebuild coreutils with the newer gmp build,
> >> then all is well, I think we need to understand this better before
> >> making this change.
> >>
> >> Did something else change in the packaging that would cause use to
> look
> >> the mapping above?
> >>
> > Saul,
> >In my testing I did not get any of these issues you mentioned
> above.
> >
> > Also I tried to reproduce the issue with coreutils as mentioned
> above, and I can not reproduce the issue for creations of an image. Can
> you verify the issue one more time?
> >
> Just to confirm, did you have a build of coreutils prior to your gmp
> changes? Which image did you build?  Be sure you build an image that
> includes coreutils, such at an -sdk image.
> 
> I can easily reproduce this issue.
> 
> Sau!
> 
I am able to reproduce the issue with sdk image, The packages(rpms) generated 
are different in r0 vs r1 version of gmp. Hence you are seeing that issue. 
Earlier libgmp.so.10 was the only library need packaging, so I guest package 
name was chosen aslibgmp10. now libgmpxx.so is also part of the package, hence 
recipe name which is gmp is chosen as the package name.  

$ ls gmp-5.0.2-r0/deploy-rpms/i586/
libgmp10-5.0.2-r0.i586.rpmlibgmp-dev-5.0.2-r0.i586.rpm  
libgmp-staticdev-5.0.2-r0.i586.rpm
libgmp-dbg-5.0.2-r0.i586.rpm  libgmp-doc-5.0.2-r0.i586.rpm

$ ls gmp-5.0.2-r1/deploy-rpms/i586/
gmp-5.0.2-r1.i586.rpm  gmp-dev-5.0.2-r1.i586.rpm  
gmp-staticdev-5.0.2-r1.i586.rpm
gmp-dbg-5.0.2-r1.i586.rpm  gmp-doc-5.0.2-r1.i586.rpm

Thanks,
Nitin

> > Thanks,
> > Nitin
> >
> >>
> >> Sau!
> >>
> >>
> >>> Signed-off-by: Nitin A Kamble
> >>> ---
> >>>meta/recipes-support/gmp/gmp.inc  |2 ++
> >>>meta/recipes-support/gmp/gmp_4.2.1.bb |2 +-
> >>>meta/recipes-support/gmp/gmp_5.0.2.bb |2 +-
> >>>3 files changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes-
> >> support/gmp/gmp.inc
> >>> index 66349e6..3c662a0 100644
> >>> --- a/meta/recipes-support/gmp/gmp.inc
> >>> +++ b/meta/recipes-support/gmp/gmp.inc
> >>> @@ -14,3 +14,5 @@ ARM_INSTRUCTION_SET = "arm"
> >>>acpaths = ""
> >>>
> >>>BBCLASSEXTEND = "native nativesdk"
> >>> +
> >>> +EXTRA_OECONF += " --enable-cxx=detect"
> >>> diff --git a/meta/recipes-support/gmp/gmp_4.2.1.bb b/meta/recipes-
> >> support/gmp/gmp_4.2.1.bb
> >>> index 74da6b8..97ac4b2 100644
> >>> --- a/meta/recipes-support/gmp/gmp_4.2.1.bb
> >>> +++ b/meta/recipes-support/gmp/gmp_4.2.1.bb
> >>> @@ -6,7 +6,7 @@ LICENSE = "LGPLv2.1+"
> >>>LIC_FILES_CHKSUM =
> >> "file://COPYING;md5=892f569a555ba9c07a568a7c0c4fa63a \
> >>>
> >> file://COPYING.LIB;md5=fbc093901857fcd118f065f900982c24 \
> >>>file://gmp-
> >> h.in;startline=6;endline=21;md5=5e25ffd16996faba8c1cd27b04b16099"

Re: [OE-core] [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2

[Kamble, Nitin A]

Hi Martin,
  I have kept my python work at nitin/python branch on poky contrib. the 2.7.2 
python is working for all arches except arm. And I am going on vacation for few 
days, and I could not finish the python arm issue arm, so if you get a chance 
you can look into the arm issue, if you have not resolved it already then I 
will look into it again once I am back from my vacation on 13th Nov.

Thanks & Regards,
Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Friday, October 14, 2011 2:12 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [review/test 3/5] python, python-native: upgrade
> from 2.6.6 to 2.7.2
> 
> On Fri, Oct 14, 2011 at 10:19:39AM +0200, Martin Jansa wrote:
> > On Thu, Oct 13, 2011 at 04:06:13PM -0700, nitin.a.kam...@intel.com
> wrote:
> > > From: Nitin A Kamble 
> > >
> >
> > This patch does not apply after
> > 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17
> >
> > can you rebase on top of oe-core?
> >
> > Also please drop
> > DEFAULT_PREFERENCE = "-27"
> >
> > we have only one python version so I guess it's not usefull at all
> > anymore
> >
> > I'll apply it manually, test it here.. and report if those modules
> are
> > build later..
> 
> seems the same as with previous version..
> 
> log.do_compile full of
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so: file
> not recognized: File format not recognized
> collect2: ld returned 1 exit status
> 
> and only built module is sqlite
> OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.0 $ ls
> Python-2.7.2/build/lib.linux-x86_64-2.7/
> _sqlite3.so
> 
> while with 2.6 we had a lot of modules
> $ ls Python-2.6.6/build/lib.linux-x86_64-2.6/
> _bisect.so  _codecs_jp.so_ctypes.so_fileio.so
> _json.so _random.so   _testcapi.so  bz2.so
> datetime.so itertools.so  parser.sospwd.so
> unicodedata.so
> _bytesio.so _codecs_kr.so_ctypes_test.so   _functools.so
> _locale.so   _socket.so   _weakref.so   cPickle.sofcntl.so
> math.so   pyexpat.so   strop.sozlib.so
> _codecs_cn.so   _codecs_tw.so_curses.so_hashlib.so
> _lsprof.so   _sqlite3.so  array.so  cStringIO.so
> future_builtins.so  mmap.so   readline.so  syslog.so
> _codecs_hk.so   _collections.so  _curses_panel.so  _heapq.so
> _multibytecodec.so   _ssl.so  audioop.socmath.so  gdbm.so
> nis.soresource.so  termios.so
> _codecs_iso2022.so  _csv.so  _elementtree.so   _hotshot.so
> _multiprocessing.so  _struct.so   binascii.so   crypt.so  grp.so
> operator.so   select.sotime.so
> 
> Can you please test that you have non-empty python-syslog python-
> resource python-elementtree python-fcntl python-zlib?
> And test build for qemuarm, because I guess that it links to -native
> libpython2.7 when you're building qemux86 on x86 host.
> 
> But it seems that python runtime works now, thanks!
> 
> Regards,
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

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

Re: [OE-core] [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2

[Kamble, Nitin A]

Hi Martin,
  I tested python inside qemux86-64 and it was working fine. I could test small 
python scripts working as expected.
Thanks,
Nitin


> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Saturday, October 22, 2011 11:28 PM
> To: Kamble, Nitin A
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [review/test 3/5] python, python-native: upgrade
> from 2.6.6 to 2.7.2
> 
> On Sat, Oct 22, 2011 at 04:54:00PM -0700, Kamble, Nitin A wrote:
> > Hi Martin,
> >   I have kept my python work at nitin/python branch on poky contrib.
> the 2.7.2 python is working for all arches except arm. And I am going
> on vacation for few days, and I could not finish the python arm issue
> arm, so if you get a chance you can look into the arm issue, if you
> have not resolved it already then I will look into it again once I am
> back from my vacation on 13th Nov.
> 
> Hi Nitin,
> 
> I've tried already and failed, but I'll try again and I guess qemux86-
> 64 (linking to host libc and failing if it's not same version as the
> one in
> sysroot) is also still broken and should be taken care of too, right?
> 
> Regards,
> 
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> > > Of Martin Jansa
> > > Sent: Friday, October 14, 2011 2:12 AM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [review/test 3/5] python, python-native:
> > > upgrade from 2.6.6 to 2.7.2
> > >
> > > On Fri, Oct 14, 2011 at 10:19:39AM +0200, Martin Jansa wrote:
> > > > On Thu, Oct 13, 2011 at 04:06:13PM -0700,
> nitin.a.kam...@intel.com
> > > wrote:
> > > > > From: Nitin A Kamble 
> > > > >
> > > >
> > > > This patch does not apply after
> > > > 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17
> > > >
> > > > can you rebase on top of oe-core?
> > > >
> > > > Also please drop
> > > > DEFAULT_PREFERENCE = "-27"
> > > >
> > > > we have only one python version so I guess it's not usefull at
> all
> > > > anymore
> > > >
> > > > I'll apply it manually, test it here.. and report if those
> modules
> > > are
> > > > build later..
> > >
> > > seems the same as with previous version..
> > >
> > > log.do_compile full of
> > > /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so:
> file
> > > not recognized: File format not recognized
> > > collect2: ld returned 1 exit status
> > >
> > > and only built module is sqlite
> > > OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.0
> $
> > > ls Python-2.7.2/build/lib.linux-x86_64-2.7/
> > > _sqlite3.so
> > >
> > > while with 2.6 we had a lot of modules $ ls
> > > Python-2.6.6/build/lib.linux-x86_64-2.6/
> > > _bisect.so  _codecs_jp.so_ctypes.so_fileio.so
> > > _json.so _random.so   _testcapi.so  bz2.so
> > > datetime.so itertools.so  parser.sospwd.so
> > > unicodedata.so
> > > _bytesio.so _codecs_kr.so_ctypes_test.so
> _functools.so
> > > _locale.so   _socket.so   _weakref.so   cPickle.so
> fcntl.so
> > > math.so   pyexpat.so   strop.sozlib.so
> > > _codecs_cn.so   _codecs_tw.so_curses.so_hashlib.so
> > > _lsprof.so   _sqlite3.so  array.so  cStringIO.so
> > > future_builtins.so  mmap.so   readline.so  syslog.so
> > > _codecs_hk.so   _collections.so  _curses_panel.so  _heapq.so
> > > _multibytecodec.so   _ssl.so  audioop.socmath.so
> gdbm.so
> > > nis.soresource.so  termios.so
> > > _codecs_iso2022.so  _csv.so  _elementtree.so   _hotshot.so
> > > _multiprocessing.so  _struct.so   binascii.so   crypt.so
> grp.so
> > > operator.so   select.sotime.so
> > >
> > > Can you please test that you have non-empty python-syslog python-
> > > resource python-elementtree python-fcntl python-zlib?
> > > And test build for qemuarm, because I guess that it links to -
> native
> > > libpython2.7 when you're building qemux86 on x86 host.
> > >
> > > But it seems that python runtime works now, thanks!
> > >
> > > Regards,
> > > --
> > > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
> 
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

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

Re: [OE-core] [PATCH 4/8] libtool: upgrade from 2.4 to 2.4.2

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Wednesday, November 16, 2011 1:50 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 4/8] libtool: upgrade from 2.4 to 2.4.2
>
> did u look at
> http://git.openembedded.org/openembedded-core-
> contrib/commit/?h=kraj/gold-
> updates&id=345f86369d165c9a41a4036c8b90662dc992f0f6

Khem,
   I did not see that commit, and I find the oecore/yocto is still behind for 
the version of libtool recipe. Any reason that commit is not in oecore?

Thanks,
Nitin

>
> On Wed, Nov 16, 2011 at 11:14 AM,   wrote:
> > From: Nitin A Kamble 
> >
> > Rebased patches to the newer source code
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../libtool/{libtool-2.4.inc => libtool-2.4.2.inc} |6 +-
> >  ...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} |2 +-
> >  ...btool-native_2.4.bb => libtool-native_2.4.2.bb} |2 +-
> >  ...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} |2 +-
> >  .../avoid_absolute_paths_for_general_utils.patch   |8 +-
> >  .../libtool/libtool/fix-final-rpath.patch  |   10 +-
> >  .../libtool/libtool/fix-rpath.patch|   12 +-
> >  .../libtool/libtool/prefix-manpage-fix.patch   |   10 +-
> >  meta/recipes-devtools/libtool/libtool/prefix.patch |   42 ++--
> >  .../libtool/libtool/rename-with-sysroot.patch  |  194
> ++--
> >  .../libtool/libtool/resolve-sysroot.patch  |   20 +--
> >  .../libtool/libtool/trailingslash.patch|   10 +-
> >  .../libtool/libtool/use-sysroot-in-libpath.patch   |8 +-
> >  .../libtool/{libtool_2.4.bb => libtool_2.4.2.bb}   |2 +-
> >  14 files changed, 159 insertions(+), 169 deletions(-)
> >  rename meta/recipes-devtools/libtool/{libtool-2.4.inc => libtool-
> 2.4.2.inc} (61%)
> >  rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb =>
> libtool-cross_2.4.2.bb} (99%)
> >  rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb =>
> libtool-native_2.4.2.bb} (98%)
> >  rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb =>
> libtool-nativesdk_2.4.2.bb} (98%)
> >  rename meta/recipes-devtools/libtool/{libtool_2.4.bb =>
> libtool_2.4.2.bb} (97%)
> >
> > diff --git a/meta/recipes-devtools/libtool/libtool-2.4.inc
> b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> > similarity index 61%
> > rename from meta/recipes-devtools/libtool/libtool-2.4.inc
> > rename to meta/recipes-devtools/libtool/libtool-2.4.2.inc
> > index e3d17b7..7f610af 100644
> > --- a/meta/recipes-devtools/libtool/libtool-2.4.inc
> > +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> > @@ -7,7 +7,7 @@ FILES_libltdl = "${libdir}/libltdl.so.*"
> >  FILES_libltdl-dev = "${libdir}/libltdl.* ${includedir}/ltdl.h"
> >  FILES_libltdl-dbg = "${libdir}/.debug/"
> >
> > -SRC_URI[md5sum] = "b32b04148ecdd7344abc6fe8bd1bb021"
> > -SRC_URI[sha256sum] =
> "13df57ab63a94e196c5d6e95d64e53262834fe780d5e82c28f177f9f71ddf62e"
> > +SRC_URI[md5sum] = "d2f3b7d4627e69e13514a40e72a24d50"
> > +SRC_URI[sha256sum] =
> "b38de44862a987293cd3d8dfae1c409d514b6c4e794ebc93648febf9afc38918"
> >
> > -EXTRA_OECONF = "--with-sysroot"
> > \ No newline at end of file
> > +EXTRA_OECONF = "--with-sysroot"
> > diff --git a/meta/recipes-devtools/libtool/libtool-cross_2.4.bb
> b/meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb
> > similarity index 99%
> > rename from meta/recipes-devtools/libtool/libtool-cross_2.4.bb
> > rename to meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb
> > index 6d512b1..d669177 100644
> > --- a/meta/recipes-devtools/libtool/libtool-cross_2.4.bb
> > +++ b/meta/recipes-devtools/libtool/libtool-cross_2.4.2.bb
> > @@ -1,6 +1,6 @@
> >  require libtool-${PV}.inc
> >
> > -PR = "r4"
> > +PR = "r0"
> >  PACKAGES = ""
> >  SRC_URI += "file://prefix.patch"
> >
> > diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.bb
> b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
> > similarity index 98%
> > rename from meta/recipes-devtools/libtool/libtool-native_2.4.bb
> > rename to meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
> > index 3d0998e..e40b9de 100644
> > --- a/meta/recipes-devtools/libtool/libtool-native_2.4.bb
> > +++ b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
> > @@ -2,7 +2,7 @@ require libtool-${PV}.inc
> >
> >  DEPENDS = ""
> >
> > -PR = "r4"
> > +PR = "r0"
> >  SRC_URI += "file://prefix.patch"
> >
> >  inherit native
> > diff --git a/meta/recipes-devtools/libtool/libtool-nativesdk_2.4.bb
> b/meta/recipes-devtools/libtool/libtool-nativesdk_2.4.2.bb
> > similarity index 98%
> > rename from meta/recipes-devtools/libtool/libtool-nativesdk_2.4.bb
> > rename to meta/recipes-devtools/libtool/libtool-nativesdk_2.4.2.bb
> > index a96d1d1..55506ed 100644
> > --- a/meta/recipes-devtools/libtool/libtool-nativesdk_2.4.bb
> > +++ b/meta/recipes-devtools/libtool/libtool-nativesdk_2.4.

Re: [OE-core] [PATCH] gcc-4.6: Fix gcc ICE on qt4-x11-free/armv7-a

[Kamble, Nitin A]

I tested this commit for qt4-x11-free for beagleboard machine, and the gcc ICE 
is gone with this commit.

Thanks,
Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Thursday, November 17, 2011 4:21 PM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] gcc-4.6: Fix gcc ICE on qt4-x11-free/armv7-a
> 
> Backport fix for PR 47551 fixes the ICE seen on armv7-a/qt4-x11-free
> Bump up SRCREV past gcc 4.6.2 release
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-devtools/gcc/gcc-4.6.inc   |9 ++--
>  meta/recipes-devtools/gcc/gcc-4.6/pr47551.patch |   63
> +++
>  2 files changed, 68 insertions(+), 4 deletions(-)
>  create mode 100644 meta/recipes-devtools/gcc/gcc-4.6/pr47551.patch
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-
> devtools/gcc/gcc-4.6.inc
> index 469457c..7bf14e3 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.6.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
> @@ -1,6 +1,6 @@
>  require gcc-common.inc
> 
> -PR = "r16"
> +PR = "r17"
> 
>  # Third digit in PV should be incremented after a minor release
>  # happens from this branch on gcc e.g. currently its 4.6.0
> @@ -8,7 +8,7 @@ PR = "r16"
>  # on branch then PV should be incremented to 4.6.1+svnr${SRCPV}
>  # to reflect that change
> 
> -PV = "4.6.1+svnr${SRCPV}"
> +PV = "4.6.2+svnr${SRCPV}"
> 
>  # BINV should be incremented after updating to a revision
>  # after a minor gcc release (e.g. 4.6.1 or 4.6.2) has been made
> @@ -16,9 +16,9 @@ PV = "4.6.1+svnr${SRCPV}"
>  # 4.6.1 then the value below will have 2 which will mean 4.6.2
>  # which will be next minor release and so on.
> 
> -BINV = "4.6.2"
> +BINV = "4.6.3"
> 
> -SRCREV = 180099
> +SRCREV = 181430
>  BRANCH = "gcc-4_6-branch"
>  FILESPATH = "${@base_set_filespath([ '${FILE_DIRNAME}/gcc-4.6' ], d)}"
> 
> @@ -71,6 +71,7 @@ SRC_URI =
> "svn://gcc.gnu.org/svn/gcc/branches;module=${BRANCH};proto=http \
>  file://gcc-with-linker-hash-style.patch \
>  file://pr46934.patch \
>  file://pr32219.patch \
> +file://pr47551.patch \
> "
> 
>  SRC_URI_append_sh3  = " file://sh3-installfix-fixheaders.patch "
> diff --git a/meta/recipes-devtools/gcc/gcc-4.6/pr47551.patch
> b/meta/recipes-devtools/gcc/gcc-4.6/pr47551.patch
> new file mode 100644
> index 000..5271ffa
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc-4.6/pr47551.patch
> @@ -0,0 +1,63 @@
> +2011-02-02  Richard Sandiford  
> +
> + gcc/
> + PR target/47551
> + * config/arm/arm.c (coproc_secondary_reload_class): Handle
> + structure modes.  Don't check neon_vector_mem_operand for
> + vector or structure modes.
> +
> + gcc/testsuite/
> + PR target/47551
> + * gcc.target/arm/neon-modes-2.c: New test.
> +
> +=== modified file 'gcc/config/arm/arm.c'
> +--- old/gcc/config/arm/arm.c 2011-02-21 14:04:51 +
>  new/gcc/config/arm/arm.c 2011-03-02 11:38:43 +
> +@@ -9139,11 +9139,14 @@
> +   return GENERAL_REGS;
> + }
> +
> ++  /* The neon move patterns handle all legitimate vector and struct
> ++ addresses.  */
> +   if (TARGET_NEON
> ++  && MEM_P (x)
> +   && (GET_MODE_CLASS (mode) == MODE_VECTOR_INT
> +-  || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT)
> +-  && neon_vector_mem_operand (x, 0))
> +- return NO_REGS;
> ++  || GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT
> ++  || VALID_NEON_STRUCT_MODE (mode)))
> ++return NO_REGS;
> +
> +   if (arm_coproc_mem_operand (x, wb) || s_register_operand (x, mode))
> + return NO_REGS;
> +
> +=== added file 'gcc/testsuite/gcc.target/arm/neon-modes-2.c'
> +--- old/gcc/testsuite/gcc.target/arm/neon-modes-2.c  1970-01-01
> 00:00:00 +
>  new/gcc/testsuite/gcc.target/arm/neon-modes-2.c  2011-02-02
> 10:02:45 +
> +@@ -0,0 +1,24 @@
> ++/* { dg-do compile } */
> ++/* { dg-require-effective-target arm_neon_ok } */
> ++/* { dg-options "-O1" } */
> ++/* { dg-add-options arm_neon } */
> ++
> ++#include "arm_neon.h"
> ++
> ++#define SETUP(A) x##A = vld3_u32 (ptr + A * 0x20)
> ++#define MODIFY(A) x##A = vld3_lane_u32 (ptr + A * 0x20 + 0x10, x##A,
> 1)
> ++#define STORE(A) vst3_u32 (ptr + A * 0x20, x##A)
> ++
> ++#define MANY(A) A (0), A (1), A (2), A (3), A (4), A (5)
> ++
> ++void
> ++bar (uint32_t *ptr, int y)
> ++{
> ++  uint32x2x3_t MANY (SETUP);
> ++  int *x = __builtin_alloca (y);
> ++  int z[0x1000];
> ++  foo (x, z);
> ++  MANY (MODIFY);
> ++  foo (x, z);
> ++  MANY (STORE);
> ++}
> +
> --
> 1.7.5.4
> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mai

Re: [OE-core] [PATCH 4/8] libtool: upgrade from 2.4 to 2.4.2

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Wednesday, November 16, 2011 2:34 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 4/8] libtool: upgrade from 2.4 to 2.4.2
> 
> On Wed, Nov 16, 2011 at 2:26 PM, Kamble, Nitin A
>  wrote:
> >
> > Khem,
> >   I did not see that commit, and I find the oecore/yocto is still
> behind for the version of libtool recipe. Any reason that commit is not
> in oecore?
> >
> > Thanks,
> 
> there were some feedback on the patch I have to look thru it.


Hi Khem,
  Any update on the libtool upgrade commit? Your and my changes are doing same 
things, Richard also has some changes for 2.4. We need to merge all these 
changes for the libtool upgrade.

Thanks,
Nitin


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

Re: [OE-core] [PATCH 4/8] libtool: upgrade from 2.4 to 2.4.2

[Kamble, Nitin A]

From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Khem Raj
Sent: Tuesday, November 22, 2011 4:19 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 4/8] libtool: upgrade from 2.4 to 2.4.2



On Tuesday, November 22, 2011, Kamble, Nitin A 
mailto:nitin.a.kam...@intel.com>> wrote:
>> -Original Message-
>> From: 
>> openembedded-core-boun...@lists.openembedded.org<mailto:openembedded-core-boun...@lists.openembedded.org>
>> [mailto:openembedded-core-boun...@lists.openembedded.org<mailto:openembedded-core-boun...@lists.openembedded.org>]
>>  On Behalf Of
>> Khem Raj
>> Sent: Wednesday, November 16, 2011 2:34 PM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [PATCH 4/8] libtool: upgrade from 2.4 to 2.4.2
>>
>> On Wed, Nov 16, 2011 at 2:26 PM, Kamble, Nitin A
>> mailto:nitin.a.kam...@intel.com>> wrote:
>> >
>> > Khem,
>> >   I did not see that commit, and I find the oecore/yocto is still
>> behind for the version of libtool recipe. Any reason that commit is not
>> in oecore?
>> >
>> > Thanks,
>>
>> there were some feedback on the patch I have to look thru it.
>
>
> Hi Khem,
>  Any update on the libtool upgrade commit? Your and my changes are doing same 
> things, Richard also has some changes for 2.4. We need to merge all these 
> changes for the libtool upgrade.

I don't have much updates to the original patches I posted
If you have time look out for any differences that I might have missed

Ok, I will merge all the 3 commits and send it out.


>
> Thanks,
> Nitin
>
>
>>
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/4] gmp: also generate the libgmpcxx library & package it properly

[Kamble, Nitin A]

From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Otavio 
Salvador
Sent: Monday, November 28, 2011 5:07 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 3/4] gmp: also generate the libgmpcxx library & 
package it properly

On Mon, Nov 28, 2011 at 22:36, 
mailto:nitin.a.kam...@intel.com>> wrote:
...
+PACKAGES =+ "libgmp10 libgmpxx4"
+FILES_libgmp10 = "${libdir}/libgmp.so.10*"
+FILES_libgmpxx4 = "${libdir}/libgmpxx.so.4*"

Why didn't you let the system to name the package using the soname by itself 
and avoid putting the soname on the glob matching?

Before the generation of libgmpxx library, there was only one library, libgmp, 
and it was getting packaged into libgmp10 package. After addition of the 
libgmpxx library the package name changed to the recipe name (gmp), in order to 
preserve the previous package name(for distro upgrades), and to let people 
avoid installation of libgmpxx if they don't need it in order to save the space 
on target, two packages are generated for each library with this scheme.

Nitin

--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  
http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/4] gmp: also generate the libgmpcxx library & package it properly

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Tuesday, November 29, 2011 12:00 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 3/4] gmp: also generate the libgmpcxx
> library & package it properly
> 
> On Mon, 2011-11-28 at 17:52 -0800, Kamble, Nitin A wrote:
> 
> > Before the generation of libgmpxx library, there was only one
> library,
> > libgmp, and it was getting packaged into libgmp10 package. After
> > addition of the libgmpxx library the package name changed to the
> > recipe name (gmp), in order to preserve the previous package name(for
> > distro upgrades), and to let people avoid installation of libgmpxx if
> > they don’t need it in order to save the space on target, two packages
> > are generated for each library with this scheme.
> 
> Right, but that's not really the point.  I think what Otavio was trying
> to ask was, why didn't you just do:
> 
> PACKAGES =+ "libgmpxx"
> FILES_libgmpxx = "${libdir}/libgmpxx${SOLIBS}"
> 
> ?  I think the way you have done it will cause the libgmp package name
> to change for people not using debian.bbclass, which is probably a bad
> thing.
> 
> p.

Thanks Phil,
  This was also works the same. And producing same rpm packages as previous 
one. So I am happy to accept this change if it helps the deb packages. Will 
resend the commit.
Nitin

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

Re: [OE-core] [PATCH 4/4] libx11-trip_1.4.4: fix the source tarall checksums

[Kamble, Nitin A]

Thank you for catching the typo. I have fixed it in the contrib branch.
Nitin

From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Otavio 
Salvador
Sent: Tuesday, November 29, 2011 11:38 AM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 4/4] libx11-trip_1.4.4: fix the source tarall 
checksums

Typo on commit log. It is libx11-trim not trip ;)
On Tue, Nov 29, 2011 at 17:30, 
mailto:nitin.a.kam...@intel.com>> wrote:
From: Nitin A Kamble mailto:nitin.a.kam...@intel.com>>

Signed-off-by: Nitin A Kamble 
mailto:nitin.a.kam...@intel.com>>
---
 
.../recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb 
|5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git 
a/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
 
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
index 7aed308..c94a3a8 100644
--- 
a/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
+++ 
b/meta/recipes-graphics/xorg-lib/libx11-trim_1.4.4.bb
@@ -13,8 +13,7 @@ SRC_URI += "file://x11_disable_makekeys.patch \
file://keysymdef_include.patch \
file://makekeys_crosscompile.patch"

-
-SRC_URI[md5sum] = "f65c9c7ecbfb64c19dbd7927160d63fd"
-SRC_URI[sha256sum] = 
"88d7238ce5f7cd123450567de7a3b56a43556e4ccc45df38b8324147c889a844"
+SRC_URI[md5sum] = "ed7c382cbf8c13425b6a66bcac0ca5d9"
+SRC_URI[sha256sum] = 
"7fe62180f08ef5f0a0062fb444591e349cae2ab5af6ad834599f5c654e6c840d"

 EXTRA_OECONF += "--with-keysymdef=${STAGING_INCDIR}/X11/ --disable-xcms "
--
1.7.6.4


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



--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  
http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx library & package it properly

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Tuesday, November 29, 2011 12:20 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx
> library & package it properly
> 
> On Tue, 2011-11-29 at 11:30 -0800, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > configure runs few checks to make sure c++ compiler and runtime are
> working
> > as expected with the --enable-cxx=detect option. And it enables
> building
> > of libgmpxx library.
> >
> > Same as earlier the libgmp.so.10.x file is packaged in the libgmp10
> package,
> > and a new package named libgmpxx4 is added for libgmpxx.so.4.x file.
> >
> > Signed-off-by: Nitin A Kamble 
> > Signed-off-by: Phil Blundell 
> 
> Um, why does this patch have my name in Signed-off-by?
> 
> p.

Because I took the code from your email.

Nitin

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

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

Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx library & package it properly

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Koen Kooi
> Sent: Tuesday, November 29, 2011 1:12 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx
> library & package it properly
> 
> 
> Op 29 nov. 2011, om 22:08 heeft Kamble, Nitin A het volgende
> geschreven:
> 
> >
> >
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> >> Of Phil Blundell
> >> Sent: Tuesday, November 29, 2011 12:20 PM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx
> >> library & package it properly
> >>
> >> On Tue, 2011-11-29 at 11:30 -0800, nitin.a.kam...@intel.com wrote:
> >>> From: Nitin A Kamble 
> >>>
> >>> configure runs few checks to make sure c++ compiler and runtime are
> >> working
> >>> as expected with the --enable-cxx=detect option. And it enables
> >> building
> >>> of libgmpxx library.
> >>>
> >>> Same as earlier the libgmp.so.10.x file is packaged in the libgmp10
> >> package,
> >>> and a new package named libgmpxx4 is added for libgmpxx.so.4.x
> file.
> >>>
> >>> Signed-off-by: Nitin A Kamble 
> >>> Signed-off-by: Phil Blundell 
> >>
> >> Um, why does this patch have my name in Signed-off-by?
> >>
> >> p.
> >
> > Because I took the code from your email.
> 
> That still doesn't explain why you added a signed-off-by without
> asking. A SOB has a defined meaning, willy nilly adding people amounts
> to fraud.
> 
Phil, if you are not ok, then I can take out your signed-off from the commit. 
Let me know.

Nitin

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

Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx library & package it properly

[Kamble, Nitin A]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Tuesday, November 29, 2011 2:06 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/4] gmp: also generate the libgmpcxx
> library & package it properly
> 
> On Tue, 2011-11-29 at 13:08 -0800, Kamble, Nitin A wrote:
> > > Um, why does this patch have my name in Signed-off-by?
> >
> > Because I took the code from your email.
> 
> Ah, I see.  Well, I appreciate you giving me the credit for that, and
> in
> this particular instance I don't have a problem with it, but as a
> general rule it isn't the done thing to add "Signed-off-by" lines
> naming
> other people.  A note in the commit message saying that you'd taken the
> code from my email would have been fine.
> 
> p.

Thank you for the explanation. BTW where can I find official rules about 
signed-off-by line

Nitin

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

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

Re: [OE-core] [PATCH 02/11] mdadm: fix CC definition in the Makefile

[Kamble, Nitin A]

Paul,
  Thanks for your feedback. I will try to incorporate your feedback in the 
commit.

Thanks,
Nitin

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Paul Menzel
> Sent: Saturday, December 03, 2011 10:08 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 02/11] mdadm: fix CC definition in the
> Makefile
> 
> Dear Nitin,
> 
> 
> thank you for your patch.
> 
> Am Freitag, den 02.12.2011, 12:20 -0800 schrieb
> nitin.a.kam...@intel.com:
> > From: Nitin A Kamble 
> >
> > By hardcoding CC's definition in the Makefile, all the gcc parameters
> > set by tune settings are lost. Causing compile failure with x32
> > toolchain
> >
> > As the bitbake defined CC is good, there is no need to redfine CC in
> > the
> 
> red*e*fine
> 
> > make file, hence removed it to fix the issue.
> >
> > This fixes bug: [YOCTO #1414]
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  .../mdadm/files/mdadm_fix_for_x32.patch|   24
> 
> >  meta/recipes-extended/mdadm/mdadm_3.2.2.bb |3 +-
> >  2 files changed, 26 insertions(+), 1 deletions(-)  create mode
> 100644
> > meta/recipes-extended/mdadm/files/mdadm_fix_for_x32.patch
> >
> > diff --git a/meta/recipes-
> extended/mdadm/files/mdadm_fix_for_x32.patch
> > b/meta/recipes-extended/mdadm/files/mdadm_fix_for_x32.patch
> > new file mode 100644
> > index 000..898e70b
> > --- /dev/null
> > +++ b/meta/recipes-extended/mdadm/files/mdadm_fix_for_x32.patch
> > @@ -0,0 +1,24 @@
> > +UpstreamStatus: pending
> > +
> > +By hardcoding CC's definition in the Makefile, all the gcc
> parameters
> > +set by tune settings are lost. Causing compile failure with x32
> > +toolchain
> > +
> > +As the bitbake defined CC is good, there is no need to redfine CC in
> > +the make file, hence removed it to fix the issue.
> > +
> > +Signed-Off-By: Nitin A Kamble 
> > +2011/12/01
> > +
> > +Index: mdadm-3.2.2/Makefile
> > +===
> > +--- mdadm-3.2.2.orig/Makefile
> >  mdadm-3.2.2/Makefile
> > +@@ -40,7 +40,7 @@ KLIBC=/home/src/klibc/klibc-0.77
> > +
> > + KLIBC_GCC = gcc -nostdinc -iwithprefix include
> > + -I$(KLIBC)/klibc/include -I$(KLIBC)/linux/include
> > + -I$(KLIBC)/klibc/arch/i386/include -I$(KLIBC)/klibc/include/bits32
> > +
> > +-CC = $(CROSS_COMPILE)gcc
> > ++#CC = $(CROSS_COMPILE)gcc
> 
> I would prefer to fix this the way it can be applied upstream. I could
> even ask them to apply it.
> 
> > + CXFLAGS = -ggdb
> > + CWFLAGS = -Wall -Werror -Wstrict-prototypes -Wextra
> > + -Wno-unused-parameter ifdef WARN_UNUSED
> 
> […]
> 
> 
> Thanks,
> 
> Paul
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/11] gst-fluendo-mpegdemux: rework the CC hack

[Kamble, Nitin A]

Hi Khem,
  Makes sense. Will try to change the fix accordingly.
Thanks,
Nitin


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Saturday, December 03, 2011 9:53 AM
> To: Patches and discussions about the oe-core layer
> Cc: hjl.to...@gmail.com
> Subject: Re: [OE-core] [PATCH 01/11] gst-fluendo-mpegdemux: rework the
> CC hack
> 
> On Fri, Dec 2, 2011 at 12:19 PM,   wrote:
> > From: Nitin A Kamble 
> >
> > This fixes bug: [YOCTO #1403]
> >
> > Earlier hack was breaking compiler parameters set by tune settings.
> And that caused x32
> > build failure. Now previous CC parameters are kept intact while
> adding new -L parameter.
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  meta/recipes-multimedia/gstreamer/gst-fluendo.inc |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
> b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
> > index 203bdba..9615454 100644
> > --- a/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
> > +++ b/meta/recipes-multimedia/gstreamer/gst-fluendo.inc
> > @@ -14,5 +14,5 @@ FILES_${PN}-dev += "${libdir}/gstreamer-0.10/*.la
> ${libdir}/gstreamer-0.10/*.a"
> >  EXTRA_OECONF = "--disable-debug --disable-valgrind"
> >
> >  # Hack to get STAGING_LIBDIR into the linker path when building
> > -CC = "${CCACHE} ${HOST_PREFIX}gcc -L${STAGING_LIBDIR}"
> > +CC += "-L${STAGING_LIBDIR}"
> 
> This looks like part of LDFLAGS more than CC to me.
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bootimg: Use STAGING_KERNEL_DIR

[Kamble, Nitin A]

ACK, This patch fixes the build. Bitbake is able to complete the creation of 
the bootable images.

Nitin


> -Original Message-
> From: Darren Hart [mailto:dvh...@linux.intel.com]
> Sent: Thursday, July 05, 2012 11:39 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Darren Hart; Zanussi, Tom; Wold, Saul; Kamble, Nitin A
> Subject: [PATCH] bootimg: Use STAGING_KERNEL_DIR
> 
> bootimg.bbclass using STAGING_DIR_HOST/kernel instead of
> STAGING_KERNEL_DIR, resulting in build failure of live images.
> 
> | install: cannot stat
> | `/usr/local/dev/yocto/fishriver-test/build/tmp/sysroots/fishriver/kern
> | el/bzImage': No such file or directory
> 
> Replace it with STAGING_KERNEL_DIR.
> 
> UNTESTED - PLEASE TEST PRIOR TO PULL.
> 
> Signed-off-by: Darren Hart 
> CC: tom.zanu...@intel.com
> CC: saul.w...@intel.com
> CC: nitin.a.kam...@intel.com
> ---
>  meta/classes/bootimg.bbclass |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
> index 370b378..a4c0e8d 100644
> --- a/meta/classes/bootimg.bbclass
> +++ b/meta/classes/bootimg.bbclass
> @@ -63,7 +63,7 @@ populate() {
>   install -d ${DEST}
> 
>   # Install bzImage, initrd, and rootfs.img in DEST for all loaders to 
> use.
> - install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage
> ${DEST}/vmlinuz
> + install -m 0644 ${STAGING_KERNEL_DIR}/bzImage ${DEST}/vmlinuz
> 
>   if [ -n "${INITRD}" ] && [ -s "${INITRD}" ]; then
>   install -m 0644 ${INITRD} ${DEST}/initrd
> --
> 1.7.10.4


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