question re gcc-runtime vs libgcc

question re gcc-runtime vs libgcc

[Angus Lees]

Sorry if the answer is obvious, but I'm trying to put together some
sdk packages and I can't see how gcc-runtime is supposed to build.

I'd like to have a static libgcc.a to isolate the sdk from whatever
libgcc.so the platform ships.  I've modified the gcc-cross{,sdk}
recipes appropriately and this part all seems to build as expected.
gcc-runtime however fails to build because libgcc doesn't get pulled
from its gcc-build-internal-* hiding place until do_install() - way
too late to be available during the build of the actual gcc-runtime
libraries.  I don't see how the situation would be any different with
a shared libgcc.so.

Can someone walk me through how this part of gcc-runtime is meant to work?


Also: I think in my case, I actually want to ship libgcc.a in
gcc-cross{,sdk} itself since it needs to correspond with the compiler
used (rather than the target sysroot as such) - but I admit I'm a bit
lost in a maze of twisty cross targets, all almost alike.  Does this
seem a reasonable thing to do?
(This made sense to me in openembedded-land, but I haven't quite got
my head around the gcc-runtime and gcc-crosssdk subtleties yet)

-- 
 - Gus

Re: question re gcc-runtime vs libgcc

[Richard Purdie]

On Fri, 2010-12-31 at 21:51 +1100, Angus Lees wrote:
> Sorry if the answer is obvious, but I'm trying to put together some
> sdk packages and I can't see how gcc-runtime is supposed to build.
> 
> I'd like to have a static libgcc.a to isolate the sdk from whatever
> libgcc.so the platform ships.  I've modified the gcc-cross{,sdk}
> recipes appropriately and this part all seems to build as expected.
> gcc-runtime however fails to build because libgcc doesn't get pulled
> from its gcc-build-internal-* hiding place until do_install() - way
> too late to be available during the build of the actual gcc-runtime
> libraries.  I don't see how the situation would be any different with
> a shared libgcc.so.
> 
> Can someone walk me through how this part of gcc-runtime is meant to work?
> 
> 
> Also: I think in my case, I actually want to ship libgcc.a in
> gcc-cross{,sdk} itself since it needs to correspond with the compiler
> used (rather than the target sysroot as such) - but I admit I'm a bit
> lost in a maze of twisty cross targets, all almost alike.  Does this
> seem a reasonable thing to do?
> (This made sense to me in openembedded-land, but I haven't quite got
> my head around the gcc-runtime and gcc-crosssdk subtleties yet)

gcc-runtime is build process for bits that can be built standalone like
libstdc++. For pieces of gcc that can't be built separately like libgcc,
we take a stashed version of it from gcc-cross and only package it as
part of gcc-runtime.

It sounds like you want to change the bits that gcc-cross is stashing
for gcc-runtime to package.

Note that the gcc recipe versions need to match. We don't support mix
and patch of different versions in a given build/sdk.

Cheers,

Richard

Re: question re gcc-runtime vs libgcc

[Angus Lees]

On Fri, Dec 31, 2010 at 23:46, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> gcc-runtime is build process for bits that can be built standalone like
> libstdc++. For pieces of gcc that can't be built separately like libgcc,
> we take a stashed version of it from gcc-cross and only package it as
> part of gcc-runtime.

ok, but where should libgcc be during the linking of libstdc++?

As far as I can see, at this point in a clean build libgcc only exists
in the temporary gcc-build-internal-* directory, which isn't in the
gcc search path.  libgcc doesn't make it out into the sysroot until
_after_ libstdc++, libssp, etc are built and gcc-runtime is installed.
 Where should gcc-cross be finding libgcc when linking libstdc++ and
friends?

 - Gus

Re: question re gcc-runtime vs libgcc

[Richard Purdie]

On Sat, 2011-01-01 at 00:22 +1100, Angus Lees wrote:
> On Fri, Dec 31, 2010 at 23:46, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > gcc-runtime is build process for bits that can be built standalone like
> > libstdc++. For pieces of gcc that can't be built separately like libgcc,
> > we take a stashed version of it from gcc-cross and only package it as
> > part of gcc-runtime.
> 
> ok, but where should libgcc be during the linking of libstdc++?
> 
> As far as I can see, at this point in a clean build libgcc only exists
> in the temporary gcc-build-internal-* directory, which isn't in the
> gcc search path.  libgcc doesn't make it out into the sysroot until
> _after_ libstdc++, libssp, etc are built and gcc-runtime is installed.
>  Where should gcc-cross be finding libgcc when linking libstdc++ and
> friends?

This is a good point. Its finding the libgcc installed by
gcc-cross-intermediate. This happens to work out ok but its not a good
design.

We're currently working on various issues in the toolchain bootstrap
process, particularly to ensure that files don't get overwritten in
staging during the bootstrap process. Those changes should help solve
this particular problem too...

Cheers,

Richard

Re: question re gcc-runtime vs libgcc

[Angus Lees]

On Sat, Jan 1, 2011 at 12:21, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> ok, but where should libgcc be during the linking of libstdc++?
>>
>> As far as I can see, at this point in a clean build libgcc only exists
>> in the temporary gcc-build-internal-* directory, which isn't in the
>> gcc search path.  libgcc doesn't make it out into the sysroot until
>> _after_ libstdc++, libssp, etc are built and gcc-runtime is installed.
>>  Where should gcc-cross be finding libgcc when linking libstdc++ and
>> friends?
>
> This is a good point. Its finding the libgcc installed by
> gcc-cross-intermediate. This happens to work out ok but its not a good
> design.

I finally got to the bottom of this:

gcc-runtime depends on virtual/${TARGET_PREFIX}gcc (aka gcc-cross) -
even though that compiler isn't functional until after gcc-runtime is
installed (due to missing libgcc).

This usually works by accident because gcc-runtime also depends on
virtual/${TARGET_PREFIX}libc-for-gcc, and {,e}glibc in turn depend on
virtual/${TARGET_PREFIX}gcc-intermediate (aka gcc-cross-intermediate).

gcc-cross-intermediate doesn't play the same libgcc games, so has a
working libgcc without gcc-runtime's cooperation.

This didn't work for me, since my libc-for-gcc arrives precompiled and
so doesn't have the same gcc-intermediate dependency.
My fix was to add a dependency on
virtual/${TARGET_PREFIX}gcc-intermediate to gcc-runtime, as I believe
it should have had originally.

(laverne-4.0)

 - Gus