I have a fully test and the qemu-native has the similar problem, and I will
resend the patch.

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, and the packagegroup-toolset-native.bb
could work for that.

1, There are a set of GCC built-in functions for atomic memory access. The
definition given in the Intel documentation allows only for the use of the
types int, long, long long as well as their unsigned counterparts. GCC will
allow any integral scalar or pointer type that is 1, 2, 4, 8 or 16 bytes in
length, suffix `_n' where n is the size of the data type.Such as:
__sync_fetch_and_add_n
__sync_fetch_and_sub_n
__sync_fetch_and_or_n
__sync_fetch_and_and_n
__sync_fetch_and_xor_n
__sync_fetch_and_nand_n
The above builtins are intended to be compatible with those described in the
Intel Itanium Processor-specific Application Binary Interface, section 7.4.

2, The glib-2.0-native and qemu-native invoke the above builtin function with
suffix `_4', and glib-2.0-native uses __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to
test the existance.

3, Not all above builtin functions are supported by all target processors.Such
as i386 does not support the functions with suffix `_4', but i486 or later
support.

4, Prior to GCC 4.5, on the Intel's processor, the default arch is i386 unless
GCC is built with the --with-arch switch. Since GCC 4.5 the default arch is
implied by the target.

5, If your host GCC is older than 4.5 and it is built without the --with-arch
switch, when you use the GCC to compile target, you should specify -march to
tell GCC what the target's arch is, otherwise i386 is used as default.

Above all, when use older GCC to compile glib-2.0-native or glib-2.0-native,
and the GCC incorrectly uses i386 as default, the above builtin function
with suffix `_4' is not referenced. We should have a check in sanity.bbclass
to tell the user if necessary to add march to BUILD_CFLAGS in this situation.

http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins
http://gcc.gnu.org/ml/gcc-help/2009-06/msg00037.html
http://gcc.gnu.org/gcc-4.5/changes.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47460
http://llvm.org/bugs/show_bug.cgi?id=11174
http://download.intel.com/design/itanium/downloads/245370.pdf

Merged into master:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3be1c1251b593b7509d12245dde4ff3daec882f1

Please verify.

Branch: Poky/master
Git rev: d823759b4594143d522eae0b2a2498436a6dcb1e

When run "bitbake qemu-native", I got the following error:
############
| In file included from /usr/include/bits/sigcontext.h:28,
|                  from /usr/include/signal.h:339,
|                  from /buildarea2/yzhao1/poky.git/build/tmp/work/i686-linux/qemu-native/1.4.0-r0/qemu-1.4.0/include/qemu-common.h:42,
|                  from fsdev/virtfs-proxy-helper.c:23:
| /usr/include/asm/sigcontext.h:28: error: expected specifier-qualifier-list before '__u64'
| /usr/include/asm/sigcontext.h:191: error: expected specifier-qualifier-list before '__u64'
|   CC    fsdev/virtio-9p-marshal.o
| make: *** [fsdev/virtfs-proxy-helper.o] Error 1
| make: *** Waiting for unfinished jobs....
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (see /buildarea2/yzhao1/poky.git/build/tmp/work/i686-linux/qemu-native/1.4.0-r0/temp/log.do_compile.17796 for further information)
#############

Test Env:
Distribution: SUSE Linux Enterprise Desktop 11 SP2  (i586)
Kernel: Linux pek-usp-10 3.0.13-0.27-pae #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) i686 i686 i386 GNU/Linux

Steps:
#############
1. Add the following line to conf/local.conf:
BUILD_CFLAGS_append = " -march=native"
2. Run "bitbake qemu-native"
#############

Reopen it.

This is another defect.

'__u64' is defined in <asm/types.h>, we should explicity include the header file in qemu-common.h to avoid the similar issue.

I will send the patch to fix it.

1, when build qemu-native on SLED 11.2, there is an error:
...
| In file included from /usr/include/bits/sigcontext.h:28,
|    from /usr/include/signal.h:339,
|    from /buildarea2/tmp/work/i686-linux/qemu-native/1.4.0-r0/
qemu-1.4.0/include/qemu-common.h:42,
|    from fsdev/virtfs-proxy-helper.c:23:
| /usr/include/asm/sigcontext.h:28: error: expected specifier-
qualifier-list before '__u64'
| /usr/include/asm/sigcontext.h:191: error: expected specifier-
qualifier-list before '__u64'
...


2, In the following `header include map', `-->' presents `include':
...
"virtfs-proxy-helper.c" --> <sys/capability.h>
...
"virtfs-proxy-helper.c" --> "qemu-common.h" --> <signal.h> -->
<bits/sigcontext.h> --> <asm/sigcontext.h> --> <linux/types.h> -->
<asm/types.h> --> <asm-generic/types.h> --> <asm-generic/int-ll64.h>
...
and '__u64' is defined in <asm-generic/int-ll64.h>.

3, The bug is found on SLED 11.2 x86. In libcap header file
/usr/include/sys/capability.h, it does evil stuff like this:
...
  25 /*
  26  * Make sure we can be included from userland by preventing
  27  * capability.h from including other kernel headers
  28  */
  29 #define _LINUX_TYPES_H
  30 #define _LINUX_FS_H
  31 #define __LINUX_COMPILER_H
  32 #define __user
  33
  34 typedef unsigned int __u32;
  35 typedef __u32 __le32;
...
This completely prevents including /usr/include/linux/types.h, etc.
The above `<asm/sigcontext.h> --> <linux/types.h>' is prevented.

4, Modify virtfs-proxy-helper.c, include <sys/capability.h> last
to workaround the similar issue.

Merged into master:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e609afe4d747059480b406602cab90b7c36a0572

Please verify.