Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH V3 0/2]fix native package compile error with gcc 4.3.4 on x86 host
Date: Thu, 28 Feb 2013 23:57:57 +0000	[thread overview]
Message-ID: <1362095877.1055.23.camel@ted> (raw)
In-Reply-To: <CAMKF1spTzzKjh+6+z2vEjXApLVFPU8MS0NrXVxa9UA=viOj8mQ@mail.gmail.com>

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





  reply	other threads:[~2013-03-01  0:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-28  7:09 [PATCH V3 0/2]fix native package compile error with gcc 4.3.4 on x86 host Hongxu Jia
2013-02-28  7:09 ` [PATCH 1/2] glib-2.0-native:fix do_configure failed " Hongxu Jia
2013-02-28  7:09 ` [PATCH 2/2] qemu-native:fix do_compile " Hongxu Jia
2013-02-28 11:06 ` [PATCH V3 0/2]fix native package compile error " Burton, Ross
2013-02-28 15:49   ` Khem Raj
2013-02-28 23:57     ` Richard Purdie [this message]
2013-03-01 12:53       ` Hongxu Jia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1362095877.1055.23.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox