[OE-core] [PATCH] u-boot.inc: properly specify CC for EXTRA_OEMAKE

[Khem Raj]

On Wed, Nov 11, 2015 at 4:37 AM, Tom Rini <trini at konsulko.com> wrote:
> On Tue, Nov 10, 2015 at 07:59:03PM -0800, Khem Raj wrote:
>>
>> > On Nov 10, 2015, at 5:09 AM, Tom Rini <trini at 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 at 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).
>

so here u-boot does have some expectations from toolchain, and at one
side it claims independence of hosted environment. So u-boot should be
adding -ffreestanding -nostdinc -nodefaultlibs  -nostdlib to its
compiler/linker flags otherwise toolchains can insert anything into
uboot
even without adding options on cmdline.

Radek, add -D__ARM_PCS_VFP to CFLAGS and that can get this going


> 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.
>

Can you explain the problem a bit more ?

> --
> Tom