[PATCH V3 0/2]fix native package compile error with gcc 4.3.4 on x86 host

[PATCH V3 0/2]fix native package compile error with gcc 4.3.4 on x86 host

[Hongxu Jia]

Change from V2: as Khem Raj suggested, use `-march=native' to cause the
compiler to auto-detect the architecture of the build computer, if the
auto-detect is unsuccessful the option has no effect.

When compile glib-2.0-native and qemu-native with with gcc 4.3.4 on x86 host ,it 
needs to add `-march' to CFLAGS, because the GCC needs this option to let the 
atomic operations ("lock free") be available.

It's a bad idea to modify bitbake.conf to add option -march to BUILD_CFLAGS,
because it's global and its side effect is unknown, such as beecrypt-native
do_compile will fail if we do that.

So it's best to test most of the native recipes to have a check about the 
similar problem and fix them separately. The glib-2.0-native and qemu-native
need to be fixed.

[YOCTO #3563]

The following changes since commit db3b539218e4ca9b348fe1338a50d91aced55c7f:

  lttng-ust: cannot find -llttng-ust-tracepoint (2013-02-26 08:02:28 -0800)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib hongxu/glib-2.0-native
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/glib-2.0-native

Hongxu Jia (2):
  glib-2.0-native:fix do_configure failed with gcc 4.3.4 on x86 host
  qemu-native:fix do_compile failed with gcc 4.3.4 on x86 host

 meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb |    6 ++++++
 meta/recipes-devtools/qemu/qemu.inc           |    6 ++++++
 2 files changed, 12 insertions(+)

-- 
1.7.10.4

[PATCH 1/2] glib-2.0-native:fix do_configure failed with gcc 4.3.4 on x86 host

[Hongxu Jia]

When compile glib-2.0-native with GCC 4.3.4 on x86 host, the GCC needs
`-march' to let the atomic operations ("lock free") be available. Pass
`-march=native' to cause the compiler to auto-detect the architecture of the
build computer, If the auto-detect is unsuccessful the option has no effect.

[YOCTO #3563]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb b/meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb
index d58d489..dbcd9b4 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb
@@ -44,6 +44,12 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = "\
             eglibc-localedata-translit-cjk-variants \
            "
 
+# When compile glib-2.0-native with GCC 4.3.4 on x86 host, the GCC needs
+# `-march' to let the atomic operations ("lock free") be available. Pass
+# `-march=native' to cause the compiler to auto-detect the architecture of the
+# build computer, If the auto-detect is unsuccessful the option has no effect.
+BUILD_CFLAGS += "-march=native"
+
 do_configure_prepend() {
 	sed -i -e '1s,#!.*,#!${USRBINPATH}/env python,' ${S}/gio/gdbus-2.0/codegen/gdbus-codegen.in
 }
-- 
1.7.10.4

[PATCH 2/2] qemu-native:fix do_compile failed with gcc 4.3.4 on x86 host

[Hongxu Jia]

When compile qemu-native with GCC 4.3.4 on x86 host, the GCC needs
`-march' to let the atomic operations ("lock free") be available. Pass
`-march=native' to cause the compiler to auto-detect the architecture of the
build computer, If the auto-detect is unsuccessful the option has no effect.

[YOCTO #3563]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-devtools/qemu/qemu.inc |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
index 6c44b31..73734f4 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -38,6 +38,12 @@ EXTRA_OECONF_class-nativesdk = "--target-list=${@get_qemu_target_list(d)} --disa
 				--disable-curl \
 				"
 
+# When compile qemu-native with GCC 4.3.4 on x86 host, the GCC needs
+# `-march' to let the atomic operations ("lock free") be available. Pass
+# `-march=native' to cause the compiler to auto-detect the architecture of the
+# build computer, If the auto-detect is unsuccessful the option has no effect.
+BUILD_CFLAGS += "-march=native"
+
 do_configure_prepend_class-native() {
 	# Undo the -lX11 added by linker-flags.patch, don't assume that host has libX11 installed
 	sed -i 's/-lX11//g' Makefile.target
-- 
1.7.10.4

Re: [PATCH V3 0/2]fix native package compile error with gcc 4.3.4 on x86 host

[Burton, Ross]

On 28 February 2013 07:09, Hongxu Jia <hongxu.jia@windriver.com> wrote:
> Change from V2: as Khem Raj suggested, use `-march=native' to cause the
> compiler to auto-detect the architecture of the build computer, if the
> auto-detect is unsuccessful the option has no effect.

What happens if you're in an environment where you're sharing sstate
between multiple developers, and the build machine is an i7 but
another developer's machine is a Core2?    These machines have
different sets of extensions available

Using the architecture as determined by bitbake seems like a better
idea (which was V1, right?) as that's embedded in the sstate hash.

Ross

Re: [PATCH V3 0/2]fix native package compile error with gcc 4.3.4 on x86 host

[Khem Raj]

On Thu, Feb 28, 2013 at 3:06 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 28 February 2013 07:09, Hongxu Jia <hongxu.jia@windriver.com> wrote:
>> Change from V2: as Khem Raj suggested, use `-march=native' to cause the
>> compiler to auto-detect the architecture of the build computer, if the
>> auto-detect is unsuccessful the option has no effect.
>
> What happens if you're in an environment where you're sharing sstate
> between multiple developers, and the build machine is an i7 but
> another developer's machine is a Core2?    These machines have
> different sets of extensions available

yes I thought about it later on. adding march=i686 when host is 32bit
and march=x86-64 which build host is 64bit in bitbake.conf is probably
one way but I feel its overkill to please an old compiler and for one recipe
so may be you should try to deduce the version of gcc. i think best is to
fix the autoconf on glib-2.0 where you would add a test to find the version
of compiler and inject the needed option to flags


>
> Using the architecture as determined by bitbake seems like a better
> idea (which was V1, right?) as that's embedded in the sstate hash.
>
> Ross
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH V3 0/2]fix native package compile error with gcc 4.3.4 on x86 host

[Richard Purdie]

On Thu, 2013-02-28 at 07:49 -0800, Khem Raj wrote:
> On Thu, Feb 28, 2013 at 3:06 AM, Burton, Ross <ross.burton@intel.com> wrote:
> > On 28 February 2013 07:09, Hongxu Jia <hongxu.jia@windriver.com> wrote:
> >> Change from V2: as Khem Raj suggested, use `-march=native' to cause the
> >> compiler to auto-detect the architecture of the build computer, if the
> >> auto-detect is unsuccessful the option has no effect.
> >
> > What happens if you're in an environment where you're sharing sstate
> > between multiple developers, and the build machine is an i7 but
> > another developer's machine is a Core2?    These machines have
> > different sets of extensions available
> 
> yes I thought about it later on. adding march=i686 when host is 32bit
> and march=x86-64 which build host is 64bit in bitbake.conf is probably
> one way but I feel its overkill to please an old compiler and for one recipe
> so may be you should try to deduce the version of gcc. i think best is to
> fix the autoconf on glib-2.0 where you would add a test to find the version
> of compiler and inject the needed option to flags
> 
> 
> >
> > Using the architecture as determined by bitbake seems like a better
> > idea (which was V1, right?) as that's embedded in the sstate hash.

How about we patch sanity.bbclass to test the gcc version and if its
4.3.4 and march isn't in BUILD_CFLAGS, we ask the user to add:

BUILD_CFLAGS_append = " -march=native"

to their local.conf, mentioning this is to fix an issue with older gccs?

Cheers,

Richard

Re: [PATCH V3 0/2]fix native package compile error with gcc 4.3.4 on x86 host

[Hongxu Jia]

On 03/01/2013 07:57 AM, Richard Purdie wrote:
> On Thu, 2013-02-28 at 07:49 -0800, Khem Raj wrote:
>> On Thu, Feb 28, 2013 at 3:06 AM, Burton, Ross <ross.burton@intel.com> wrote:
>>> On 28 February 2013 07:09, Hongxu Jia <hongxu.jia@windriver.com> wrote:
>>>> Change from V2: as Khem Raj suggested, use `-march=native' to cause the
>>>> compiler to auto-detect the architecture of the build computer, if the
>>>> auto-detect is unsuccessful the option has no effect.
>>> What happens if you're in an environment where you're sharing sstate
>>> between multiple developers, and the build machine is an i7 but
>>> another developer's machine is a Core2?    These machines have
>>> different sets of extensions available
>> yes I thought about it later on. adding march=i686 when host is 32bit
>> and march=x86-64 which build host is 64bit in bitbake.conf is probably
>> one way but I feel its overkill to please an old compiler and for one recipe
>> so may be you should try to deduce the version of gcc. i think best is to
>> fix the autoconf on glib-2.0 where you would add a test to find the version
>> of compiler and inject the needed option to flags
>>
>>
>>> Using the architecture as determined by bitbake seems like a better
>>> idea (which was V1, right?) as that's embedded in the sstate hash.
> How about we patch sanity.bbclass to test the gcc version and if its
> 4.3.4 and march isn't in BUILD_CFLAGS, we ask the user to add:
>
> BUILD_CFLAGS_append = " -march=native"
>
> to their local.conf, mentioning this is to fix an issue with older gccs?
Got it, I will work on it.

Thanks
Hongxu

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