From: Tom Rini <trini@konsulko.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>,
Otavio Salvador <otavio.salvador@ossystems.com.br>
Subject: Re: [PATCH] u-boot.inc: properly specify CC for EXTRA_OEMAKE
Date: Wed, 11 Nov 2015 07:37:15 -0500 [thread overview]
Message-ID: <20151111123715.GK8060@bill-the-cat> (raw)
In-Reply-To: <58549136-994C-4F05-9310-5235F4E2F618@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]
On Tue, Nov 10, 2015 at 07:59:03PM -0800, Khem Raj wrote:
>
> > On Nov 10, 2015, at 5:09 AM, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Nov 05, 2015 at 03:23:48PM +0100, Carlos Rafael Giani wrote:
> >> On 11/05/2015 03:22 PM, Otavio Salvador wrote:
> >>> Hello Carlos,
> >>>
> >>> On Thu, Nov 5, 2015 at 11:16 AM, Carlos Rafael Giani
> >>> <dv@pseudoterminal.org> wrote:
> >>>> So, this is because of the TOOLCHAIN_OPTIONS ?
> >>>> Also, what about the ${CC} ? Right now it won't work properly with clang for
> >>>> example.
> >>> The clang is problem might involve us to rework something but all this
> >>> needs to be based on last U-Boot releases; we shouldn't put
> >>> workarounds and hacks on OE-Core without good reasons.
> >>>
> >>> Has the clang been tested with 2015.10?
> >>
> >> Still, then I'd add something to output an error message like
> >> "U-Boot can only be compiled with gcc". Right now, the error
> >> messages that would occur would be highly confusing and misleading.
> >
> > U-Boot supports clang, but it's not as well tested as other things.
> > However, this patch is still wrong as we do not want to try and force
> > flags to gcc, just like we don't with the kernel. For more on U-Boot,
> > see doc/README.clang (And then possibly do some fixups, I'm not having
> > super luck with it right now, but I'm in a bit of a rush right now).
> >
>
> This patch is however injecting flags externally, so in case you were to use
> clang with OE in context the TOOLCHAIN_OPTION will be appropriately set as well
> so this should work fine. As far as u-boot’s own build architecture is concerned
> its fine. I think the real problem is arising due to toolchain defaults in OE
> e.g. when we default to hard float gcc does not really use hard-float unless specified on commandline. One can argue that OE should be fixed for that or gcc
> should be using the right ABI as default which corresponds to default configs as used for gcc in toolchain.
>
> One concern here I have is that when we switch float-abi like this, what is the impact on u-boot itself, has it ever been build and tested with hard-float, as long as there are no float function arguments this should not do anything to code
> but then we need report on this.
First, no, like the kernel, you do not go mucking with the float options
that U-Boot wants to use. OE is correctly today letting U-Boot enforce
what it wants (and then from time to time exposing latent bug from cases
where the toolchain ends up overriding us).
Second, it's currently a bit of a moot point as U-Boot for clang for ARM
needs a bit of attention again as how we deal with global data is once
again making clang unhappy and no one has gone and fixed it again.
--
Tom
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
next prev parent reply other threads:[~2015-11-11 12:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-04 16:06 [PATCH] u-boot.inc: properly specify CC for EXTRA_OEMAKE Radek Dostal
2015-11-05 13:14 ` Otavio Salvador
2015-11-05 13:16 ` Carlos Rafael Giani
2015-11-05 14:22 ` Otavio Salvador
2015-11-05 14:23 ` Carlos Rafael Giani
2015-11-10 13:09 ` Tom Rini
2015-11-11 3:59 ` Khem Raj
2015-11-11 12:37 ` Tom Rini [this message]
2015-11-11 16:21 ` Khem Raj
2015-11-05 15:19 ` Radek Dostál
2015-11-05 15:32 ` Burton, Ross
2015-11-05 15:47 ` Otavio Salvador
2015-11-05 16:02 ` Radek Dostál
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=20151111123715.GK8060@bill-the-cat \
--to=trini@konsulko.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio.salvador@ossystems.com.br \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.