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

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

[Radek Dostal]

${TOOLCHAIN_OPTIONS} does not contain some important flags such as
"-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8". It only
specifies sysroot as mentioned in commit 923eb657 "u-boot.inc: update
linker arguments to pass --sysroot arg"

Fixes bug: u-boot 2014.04 build breaks with error:
"fatal error: gnu/stubs-soft.h: No such file or directory"
when building with hard float compiler as compiler does not receive
flag "-mfloat-abi=hard"

Before this patch only gcc compiler could be used due to CC explicitly
being set to gcc.

Signed-off-by: Radek Dostal <radek.dostal@streamunlimited.com>
Acked-by: Carlos Rafael Giani <dv@pseudoterminal.org>
---
 meta/recipes-bsp/u-boot/u-boot.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
index e66ffd1..be22e0c 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -14,7 +14,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 inherit uboot-config deploy
 
-EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}" V=1'
+EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC}" V=1'
 EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"'
 
 PACKAGECONFIG ??= "openssl"
-- 
1.9.1

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

[Otavio Salvador]

Hello Radek,

On Wed, Nov 4, 2015 at 2:06 PM, Radek Dostal
<radek.dostal@streamunlimited.com> wrote:
> ${TOOLCHAIN_OPTIONS} does not contain some important flags such as
> "-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8". It only
> specifies sysroot as mentioned in commit 923eb657 "u-boot.inc: update
> linker arguments to pass --sysroot arg"
>
> Fixes bug: u-boot 2014.04 build breaks with error:
> "fatal error: gnu/stubs-soft.h: No such file or directory"
> when building with hard float compiler as compiler does not receive
> flag "-mfloat-abi=hard"
>
> Before this patch only gcc compiler could be used due to CC explicitly
> being set to gcc.
>
> Signed-off-by: Radek Dostal <radek.dostal@streamunlimited.com>
> Acked-by: Carlos Rafael Giani <dv@pseudoterminal.org>

Nack!

The U-Boot is close to the Linux kernel regarding the use of the
compiler and does a huge set of handling internally to properly pass
options depending on the SoC, arch and others.

This build error has been fixed in new U-Boot releases and if the
board required an old version (and cannot be updated) the fix should
be done on the recipe and not on the common file as it can change,
behind the scenes, what is in use for several recipes without notice.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

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

[Carlos Rafael Giani]

So, this is because of the TOOLCHAIN_OPTIONS ?
Also, what about the ${CC} ? Right now it won't work properly with clang 
for example.

On 11/05/2015 02:14 PM, Otavio Salvador wrote:
> Hello Radek,
>
> On Wed, Nov 4, 2015 at 2:06 PM, Radek Dostal
> <radek.dostal@streamunlimited.com> wrote:
>> ${TOOLCHAIN_OPTIONS} does not contain some important flags such as
>> "-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8". It only
>> specifies sysroot as mentioned in commit 923eb657 "u-boot.inc: update
>> linker arguments to pass --sysroot arg"
>>
>> Fixes bug: u-boot 2014.04 build breaks with error:
>> "fatal error: gnu/stubs-soft.h: No such file or directory"
>> when building with hard float compiler as compiler does not receive
>> flag "-mfloat-abi=hard"
>>
>> Before this patch only gcc compiler could be used due to CC explicitly
>> being set to gcc.
>>
>> Signed-off-by: Radek Dostal <radek.dostal@streamunlimited.com>
>> Acked-by: Carlos Rafael Giani <dv@pseudoterminal.org>
> Nack!
>
> The U-Boot is close to the Linux kernel regarding the use of the
> compiler and does a huge set of handling internally to properly pass
> options depending on the SoC, arch and others.
>
> This build error has been fixed in new U-Boot releases and if the
> board required an old version (and cannot be updated) the fix should
> be done on the recipe and not on the common file as it can change,
> behind the scenes, what is in use for several recipes without notice.
>

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

[Otavio Salvador]

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?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

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

[Carlos Rafael Giani]

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.

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

[Radek Dostál]

Hi Otavio,

> Nack!
>
> The U-Boot is close to the Linux kernel regarding the use of the
> compiler and does a huge set of handling internally to properly pass
> options depending on the SoC, arch and others.
>
> This build error has been fixed in new U-Boot releases and if the
> board required an old version (and cannot be updated) the fix should
> be done on the recipe and not on the common file as it can change,
> behind the scenes, what is in use for several recipes without notice.

Thanks a lot for your valuable input. I was not aware of the fact that 
it was fixed in the upstream already. If you know the commit out of your 
head, it would be great if you could share it.

Thanks,
Radek

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

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

On 5 November 2015 at 15:19, Radek Dostál <radek.dostal@streamunlimited.com>
wrote:

> Thanks a lot for your valuable input. I was not aware of the fact that it
> was fixed in the upstream already. If you know the commit out of your head,
> it would be great if you could share it.
>

For what it's worth 2015.10 is queued for master already.

Ross

[-- Attachment #2: Type: text/html, Size: 777 bytes --]

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

[Otavio Salvador]

On Thu, Nov 5, 2015 at 1:19 PM, Radek Dostál
<radek.dostal@streamunlimited.com> wrote:
>> This build error has been fixed in new U-Boot releases and if the
>> board required an old version (and cannot be updated) the fix should
>> be done on the recipe and not on the common file as it can change,
>> behind the scenes, what is in use for several recipes without notice.
>
> Thanks a lot for your valuable input. I was not aware of the fact that it
> was fixed in the upstream already. If you know the commit out of your head,
> it would be great if you could share it.

I don't know; I strongly advise the upgrade for the board if you have
the resources (schematic, time, ...) otherwise a recipe workaround is
the best alternative.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

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

[Radek Dostál]

On 11/05/2015 04:47 PM, Otavio Salvador wrote:
> I don't know; I strongly advise the upgrade for the board if you have
> the resources (schematic, time, ...) otherwise a recipe workaround is
> the best alternative.

Thank you, update of the u-boot is planned for early 2016, till that 
time we have to live with the recipe workaround.

Thanks,
Radek

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

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

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

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

[Khem Raj]

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

> -- 
> Tom
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Tom Rini]

[-- 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 --]

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

[Khem Raj]

On Wed, Nov 11, 2015 at 4:37 AM, Tom Rini <trini@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@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).
>

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