Re: Standalone gcc library builds

[Richard Purdie <rpurdie@rpsys.net>]

On Tue, 2010-03-30 at 12:14 +0200, Koen Kooi wrote:
> On 30-03-10 11:42, Richard Purdie wrote:
> > On Tue, 2010-03-30 at 11:33 +0200, Koen Kooi wrote:
> >> Can't we have seperate recipes for ssp, stdc++, fortran, java, etc? I
> >> don't think we need USEFLAGs for this when we build them seperately anyway.
> > 
> > We'd not be using USEFLAGS, we'd just be looking at the line which tells
> > gcc itself which bits to build. Having separate recipes doesn't solve
> > the problem since we'd still have to work out whether the compiler for a
> > given lib was built and then we enter a dependency nightmare working out
> > which packages need which combinations of compilers and compiler libs.
> > 
> > So we can have separate recipes but think through the issues and see
> > whether you still like the idea... 
> 
> Let's put it in a different way:
> 
> Can we stop artificially limiting the toolchain options and have people
> opt-out instead of opt-in for stuff? I really need a full featured
> toolchain :)

I see no reason why the default compiler shouldn't be the fully featured
one and then distros and users can turn off the bits they don't want if
they choose to.

Is that the issue you mean or is there a concern I'm missing?

I can see the other side though, its a pain having to fight fortran
build failures when upgrading the compiler if you never use fortran. Its
this point where it becomes a pain to have so many old versions of
things as this would be much simpler to arrange and maintain if we had
less gcc versions. I worry about trying to add gcc-runtime to OE for
this reason.

[remark about Poky removed]

Cheers,

Richard