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

From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 5/6] gcc-cross: Pass EXTRA_OECONF_GCC_FLOAT to configure
Date: Thu, 7 May 2015 14:05:03 +0200	[thread overview]
Message-ID: <20150507120503.GC2400@jama> (raw)
In-Reply-To: <1430994286.8074.129.camel@linuxfoundation.org>

On Thu, May 07, 2015 at 11:24:46AM +0100, Richard Purdie wrote:
> On Thu, 2015-05-07 at 00:17 -0700, Khem Raj wrote:
> > > On May 6, 2015, at 11:53 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > > 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
> 
> Agreed, the other option is we have gcc pull the right config from the
> sysroot in question.

FWIW: when we were upgrading from Dylan to Dizzy one MACHINE with hf, we
noticed that few recipes weren't respecting CC variable and ended with
mixing soft and hard fp which was luckily detected in build time by
linker, so easy to fix.

Having at least QA check which will warn user that some compiled binary
has different float ABI then enabled in bitbake environment could be
useful. But I agree that it's recipe fault if it doesn't respect CC or
*FLAGS variables and we should fix it there instead of building
gcc-cross twice (if you have 2 arm MACHINEs with different float ABI).

Another option would be mfloat-abi poisoning if possible like we do with
default sysroot parameter, so that the usage of default value is
detected as soon as possible.

Regards,

> 
> > > 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
> 
> On device is a completely different story. That gcc is target specific
> and *should* have the right flags set. That isn't what the patch in this
> thread is about though. On target gcc has always been target specific
> and will remain so.
> 
> Cheers,
> 
> Richard
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com