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 5/6] gcc-cross: Pass EXTRA_OECONF_GCC_FLOAT to configure
Date: Thu, 07 May 2015 07:53:10 +0100	[thread overview]
Message-ID: <1430981590.8074.127.camel@linuxfoundation.org> (raw)
In-Reply-To: <000AAC87-CE74-45DC-A006-D4704D8841D8@gmail.com>

On Wed, 2015-05-06 at 23:47 -0700, Khem Raj wrote:
> > On May 6, 2015, at 1:11 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > 
> > But we build gcc-cross-arm once. This will cause it to rebuild depending
> > on which machine you target? Worse, it likely will now do this for all
> > architectures, not just arm.
> 
> only when float ABI changes which may be common across a subset of architectures.
> 
> although, I think its going to become a severe usability issue. Look
> at the archives there are so many issues reported in various forums which end up exactly to this problem, since users expect
> that once they installed the SDK it works out of box for the default architecture which is not
> the case. It just seems wrong build optimization to make it common per arch it if we can’t have user expectations met.

To be honest I haven't seen that many reports of the problem. We do ship
an environment file and in that file we have the options gcc needs to
work, the sysroot, the other cflags and the float abi. Unless we go back
to a setup of hardcoding the cflags into gcc and have a gcc per set of
cflags, this isn't going to work since it solves part of the problem but
not all of it.

Our other alternative is to wrap gcc with a script (preferred in PATH)
which ensures the right cflags are present. I'd obviously prefer not to
do that but it is an option if we believe people can't cope with the
environment script.

Cheers,

Richard




  reply	other threads:[~2015-05-07  6:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06  7:04 [PATCH 0/6] gcc-5, aarch64 support for musl Khem Raj
2015-05-06  7:04 ` [PATCH 1/6] glibc: ignore for musl/uclibc but only for target recipes Khem Raj
2015-05-06  7:04 ` [PATCH 2/6] gcc: Add 5 recipes Khem Raj
2015-05-06  7:04 ` [PATCH 3/6] insane: Support aarch64 on musl Khem Raj
2015-05-06  7:04 ` [PATCH 4/6] gcc-4.9, gcc-5: Use variable SYSTEMLIBS_DIR instead of hardcoding it for aarch64 Khem Raj
2015-05-06  7:04 ` [PATCH 5/6] gcc-cross: Pass EXTRA_OECONF_GCC_FLOAT to configure Khem Raj
2015-05-06  8:11   ` Richard Purdie
2015-05-07  6:47     ` Khem Raj
2015-05-07  6:53       ` Richard Purdie [this message]
2015-05-07  7:17         ` Khem Raj
2015-05-07 10:24           ` Richard Purdie
2015-05-07 12:05             ` Martin Jansa
2015-05-06  7:04 ` [PATCH 6/6] libart-lgpl: Fix cross compiling Khem Raj
2015-05-06 10:59   ` Burton, Ross

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=1430981590.8074.127.camel@linuxfoundation.org \
    --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