[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    [OE-core] [PATCH V3 0/2]fix native package compile error with gcc 4.3.4 on x86 host
From:       richard.purdie () linuxfoundation ! org (Richard Purdie)
Date:       2013-02-28 23:57:57
Message-ID: 1362095877.1055.23.camel () ted
[Download RAW message or body]

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 at intel.com> wrote:
> > On 28 February 2013 07:09, Hongxu Jia <hongxu.jia at 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





[prev in list] [next in list] [prev in thread] [next in thread]