fix native package compile error with gcc 4.3.4 on x86 host

PATCH Superseded Hongxu Jia 4 participants 7 messages Feb 28, 2013 – Mar 1, 2013

Share & tools

Hongxu Jia

author

2013-02-28 07:25 UTC #0 lore raw

v3 cover fix native package compile error with gcc 4.3.4 on x86 host

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

Signature · 1 line

1.7.10.4

Hongxu Jia

author

2013-02-28 07:25 UTC #1 lore raw

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

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 <[email protected]>

---
 meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb |    6 ++++++
 1 file changed, 6 insertions(+)

meta/recipes-core/glib-2.0/glib-2.0_2.34.3.bb +6 -0

index d58d489..dbcd9b4 100644
@@ -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
 }

Signature · 1 line

1.7.10.4

Hongxu Jia

author

2013-02-28 07:25 UTC #2 lore raw

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

In reply to 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 <[email protected]>

---
 meta/recipes-devtools/qemu/qemu.inc |    6 ++++++
 1 file changed, 6 insertions(+)

meta/recipes-devtools/qemu/qemu.inc +6 -0

index 6c44b31..73734f4 100644
@@ -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

Signature · 1 line

1.7.10.4

Burton, Ross

2013-02-28 11:23 UTC #3 lore raw

In reply to Hongxu Jia

Quoted 3 lines · 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.

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

Khem Raj

2013-02-28 16:06 UTC #4 lore raw

Quoted 9 lines · Ross

Quoted 3 lines · 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.
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

Quoted 10 lines

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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Richard Purdie

2013-03-01 00:14 UTC #5 lore raw

Quoted 11 lines · Khem Raj

Quoted 9 lines · Ross
Quoted 3 lines · 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.
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

Quoted 11 lines

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
Quoted 3 lines
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

Hongxu Jia

author

2013-03-01 13:10 UTC #6 lore raw

Quoted 18 lines · Richard Purdie

Quoted 17 lines · Khem Raj
Quoted 8 lines · Ross
Quoted 3 lines · 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.
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

Quoted 8 lines

Quoted 2 lines
Quoted 2 lines
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

Quoted 10 lines

Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core