[OE-core] [PATCH 5/6] gcc-cross: Pass EXTRA_OECONF_GCC_FLOAT to configure

Khem Raj raj.khem at gmail.com
Thu May 7 07:17:28 UTC 2015


> On May 6, 2015, at 11:53 PM, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
> 
> On Wed, 2015-05-06 at 23:47 -0700, Khem Raj wrote:
>>> On May 6, 2015, at 1:11 AM, Richard Purdie <richard.purdie at 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.

search for "gnu/stubs-soft.h not found”
and most of the items you will see are OE related.
some issues are quite complex which happen in applications e.g. wrong atomics use

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

its also how the target libraries are compiled should match the ABI flags for target gcc

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

Would solve the cross compile scenario but on-device scenario I am not sure

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150507/67090255/attachment-0002.sig>


More information about the Openembedded-core mailing list