Standalone gcc library builds

Standalone gcc library builds

[Richard Purdie]

Hi,

We currently build gcc and all its runtime libraries as part of at least
"gcc-cross", "gcc", "gcc-cross-sdk". Packaging of these libraries varies
between the different recipes and is a pretty scary place for things to
go wrong which I've frequently seen.

I'm working on the idea of having the above packages just generate the
compiler binaries (host tools) and having a "gcc-runtime" package which
builds all the libraries (target libs). I think can make this work
expect for libgcc itself which is proving a real pain (unsurprisingly).

For libgcc, we can save the bits it needs from the gcc build into
staging and then make it build that way, or just build it as a special
case as part of gcc, stash it in staging, then package it as part of
gcc-runtime.

Does anyone have any better ideas of experience of playing with libgcc?

Cheers,

Richard

Re: Standalone gcc library builds

[Khem Raj]

On (29/03/10 16:53), Richard Purdie wrote:
> Hi,
> 
> We currently build gcc and all its runtime libraries as part of at least
> "gcc-cross", "gcc", "gcc-cross-sdk". Packaging of these libraries varies
> between the different recipes and is a pretty scary place for things to
> go wrong which I've frequently seen.
> 
> I'm working on the idea of having the above packages just generate the
> compiler binaries (host tools) and having a "gcc-runtime" package which
> builds all the libraries (target libs). I think can make this work
> expect for libgcc itself which is proving a real pain (unsurprisingly).
> 
> For libgcc, we can save the bits it needs from the gcc build into
> staging and then make it build that way, or just build it as a special
> case as part of gcc, stash it in staging, then package it as part of
> gcc-runtime.
> 
> Does anyone have any better ideas of experience of playing with libgcc?

I have had gcc build all runtimes libraries separately. I think we should
device gcc build and we can disable building certain directories via
--disable-<dir>. We dont have to stash libgcc. Its not a big library and
its probably better to rebuild it along with rest of runtime libraries IMO
and probably we should have packages for each language runtime so people
who dont need C++ or Java or fortran dont have to build those. The same
should be tunable in gcc builds too.

> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Standalone gcc library builds

[Richard Purdie]

On Mon, 2010-03-29 at 10:42 -0700, Khem Raj wrote:
> I have had gcc build all runtimes libraries separately. I think we should
> device gcc build and we can disable building certain directories via
> --disable-<dir>. We dont have to stash libgcc. Its not a big library and
> its probably better to rebuild it along with rest of runtime libraries IMO
> and probably we should have packages for each language runtime so people
> who dont need C++ or Java or fortran dont have to build those. The same
> should be tunable in gcc builds too.

I talked with Khem on irc but just for the record here, I've done some
testing with gcc 4.3.3 in Poky and have pushed my results to:

http://git.pokylinux.org/cgit.cgi/poky/log/?h=master-gcc-runtime-testing

This adds a gcc-runtime recipe which builds libgcc, libssp and libstdc++
as test cases. It will be possible to build other runtime libs
conditionally on whether they're enabled like libfortran easily enough.

We have to add in an extra dependency layer to the compiler bootstrap
but that isn't an issue.

The bit that is ugly is the stashing of headers in staging by gcc-cross.
The issue is we want to build the target libs in our normal "target"
context so cross.bbclass is not used by gcc-runtime. This means
HOST==TARGET and hence building gcc itself fails.

Discussion on how best to do this welcome :)

Cheers,

Richard

Re: Standalone gcc library builds

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29-03-10 23:42, Richard Purdie wrote:
> On Mon, 2010-03-29 at 10:42 -0700, Khem Raj wrote:
>> I have had gcc build all runtimes libraries separately. I think we should
>> device gcc build and we can disable building certain directories via
>> --disable-<dir>. We dont have to stash libgcc. Its not a big library and
>> its probably better to rebuild it along with rest of runtime libraries IMO
>> and probably we should have packages for each language runtime so people
>> who dont need C++ or Java or fortran dont have to build those. The same
>> should be tunable in gcc builds too.
> 
> I talked with Khem on irc but just for the record here, I've done some
> testing with gcc 4.3.3 in Poky and have pushed my results to:
> 
> http://git.pokylinux.org/cgit.cgi/poky/log/?h=master-gcc-runtime-testing
> 
> This adds a gcc-runtime recipe which builds libgcc, libssp and libstdc++
> as test cases. It will be possible to build other runtime libs
> conditionally on whether they're enabled like libfortran easily enough.

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.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLscWDMkyGM64RGpERAiGWAKC3DUZnFvM4fiS5+eBj83MMJcLB2wCeOaEW
7qaQ7rDPo+K4cXaoZejxdJY=
=o64b
-----END PGP SIGNATURE-----

Re: Standalone gcc library builds

[Richard Purdie]

On Tue, 2010-03-30 at 11:33 +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 29-03-10 23:42, Richard Purdie wrote:
> > On Mon, 2010-03-29 at 10:42 -0700, Khem Raj wrote:
> >> I have had gcc build all runtimes libraries separately. I think we should
> >> device gcc build and we can disable building certain directories via
> >> --disable-<dir>. We dont have to stash libgcc. Its not a big library and
> >> its probably better to rebuild it along with rest of runtime libraries IMO
> >> and probably we should have packages for each language runtime so people
> >> who dont need C++ or Java or fortran dont have to build those. The same
> >> should be tunable in gcc builds too.
> > 
> > I talked with Khem on irc but just for the record here, I've done some
> > testing with gcc 4.3.3 in Poky and have pushed my results to:
> > 
> > http://git.pokylinux.org/cgit.cgi/poky/log/?h=master-gcc-runtime-testing
> > 
> > This adds a gcc-runtime recipe which builds libgcc, libssp and libstdc++
> > as test cases. It will be possible to build other runtime libs
> > conditionally on whether they're enabled like libfortran easily enough.
> 
> 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... 

Cheers,

Richard

Re: Standalone gcc library builds

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30-03-10 11:42, Richard Purdie wrote:
> On Tue, 2010-03-30 at 11:33 +0200, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 29-03-10 23:42, Richard Purdie wrote:
>>> On Mon, 2010-03-29 at 10:42 -0700, Khem Raj wrote:
>>>> I have had gcc build all runtimes libraries separately. I think we should
>>>> device gcc build and we can disable building certain directories via
>>>> --disable-<dir>. We dont have to stash libgcc. Its not a big library and
>>>> its probably better to rebuild it along with rest of runtime libraries IMO
>>>> and probably we should have packages for each language runtime so people
>>>> who dont need C++ or Java or fortran dont have to build those. The same
>>>> should be tunable in gcc builds too.
>>>
>>> I talked with Khem on irc but just for the record here, I've done some
>>> testing with gcc 4.3.3 in Poky and have pushed my results to:
>>>
>>> http://git.pokylinux.org/cgit.cgi/poky/log/?h=master-gcc-runtime-testing
>>>
>>> This adds a gcc-runtime recipe which builds libgcc, libssp and libstdc++
>>> as test cases. It will be possible to build other runtime libs
>>> conditionally on whether they're enabled like libfortran easily enough.
>>
>> 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 :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLsc8gMkyGM64RGpERAspvAJkBUOMCqc6Z4hB7eU0lmzRGStBHBQCglZw/
CDixQmIv66vduo4Yoi2SQGk=
=dIFy
-----END PGP SIGNATURE-----

Re: Standalone gcc library builds

[Richard Purdie]

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

Re: Standalone gcc library builds

[Khem Raj]

On Tue, Mar 30, 2010 at 3:29 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> 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.

I think we should default to C,C++ which is most commonly used combination
but at the same time it would be nice if developer could disable C++ or enable
fortran or java or objc, ada, go language or whatever



>
> [remark about Poky removed]
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>