Openembedded Core Discussions
 help / color / mirror / Atom feed
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 --]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox