[OE-core] how to pass or set specific gcc flags?

[Richard Purdie]

On Mon, 2011-08-08 at 10:46 -0500, Kumar Gala wrote:
> On Aug 8, 2011, at 9:55 AM, Richard Purdie wrote:
> 
> > On Sun, 2011-08-07 at 12:08 -0500, Kumar Gala wrote:
> >> We'd like to pass:
> >> 
> >> --enable-targets=all
> >> 
> >> on ppc when we target a 64-bit platform but happen to build a 32-bit
> >> toolchain & rootfs, its useful to still have 64-bit support in the
> >> compiler to build a 64-bit kernel if desired in this scenario.  Also,
> >> this seems useful for the multilib situation.
> >> 
> >> Wondering what the best way of doing this.  Adding something into the
> >> tune-ppcFOOBAR file but not sure how to do that so it gets picked up
> >> by the right toolchain pass.  And what do we even override?  I
> >> suggested adding a GCC_EXTRA_OECONF.
> > 
> > I'd caution against this since we don't currently handle packaging of
> > toolchains directly using multilibs and I suspect the compiler wouldn't
> > bootstrap properly either.
> > 
> > Its not the compiler itself I worry about but pieces like libc and
> > libgcc.
> 
> I dont think they have any issue with --enable-targets on ppc.

No, I'm suggesting the build system can't cope with that, e.g. if there
are multiple libgcc's produced we have no way to correctly individually
package them.

> The issue is I'm trying to look at this based on our customer view
> point.  The majority of our customers that would utilize 64-bit are
> going to want to start with a 32-bit rootfs and than add some 64-bit
> bits to it.  Rather than the other way.

Ok, so why not define your multilib the other way around? Start with a
64 bit system and add 64 bit as the multilib?

> This is one reason I'm asking about how to deal with tune-ppce5500.inc
> and 32-bit vs 64-bit.

In these cases you need to define 32 and 64 bit tunes and then you can
select the appropriate tune as needed.

> Now it might be ok short term since we have 2 toolchains, etc for
> multilib.  However at some point (shortly) we have to address this.
> 
> I think the 2 toolchains is UGLY and confusing to customers/users.
> While I understand it from the point of view on how to take steps to
> get multilib going it doesn't mean we shouldnt start thinking about
> how to address these issues.

We've been working on multilb for a while and so far its taken some
significant work by several people to get things working as they are
now. We really need to spend some some and stabilise and consolidate
that work so far at this point.

I'm more than happy to think about consolidating the toolchain pieces,
its on the future ideas list but I don't believe its appropriate right
now. I'd like the work done so far to work properly before we try
enhancing it further.

I'd hope that the toolchains are actually pretty hidden from
customers/users to, I don't think its as ugly as you're making out and
actually has some benefits.

Cheers,

Richard