bug 1169 eglibc doesn't depend on gcc version correctly

bug 1169 eglibc doesn't depend on gcc version correctly

[Robert Yang]

Hi experts,

There is a bug 1169: eglibc doesn't depend on gcc version correctly,

The produce steps are:

1) In the first build dir(e.g, build_1), edit conf/local.conf:
    SSTATE_DIR = /path/to/share_sstate

    $ bitbake meta-toolchain

2) In the second build dir(e.g, build_2), edit local.conf:
    SSTATE_DIR = /path/to/share_sstate
    SDKGCCVERSION="4.5.1"
    GCCVERSION="4.5.1"

    $ bitbake meta-toolchain

Then we will notice the error:
| error: Failed dependencies:
|       libgcc1 >= 4.6.0 is needed by eglibc-utils-2.13-r1+svnr14157.armv5te

The reason is a little complicated:
As we can see that eglibc's RDPENDS should have 'libgcc', but eglibc's
DEPENDS(not RDEPENDS) can't have libgcc, otherwise there would be loop
dependencies(since libgcc already DEPENDS on eglibc), this causes
eglibc.do_package can't detect that the version of libgcc or gcc
has been changed from 4.6 to 4.5.1, so it would mirror the
sstate-eglibc-xxx_package.tgz(which is stored by gcc 4.6) from the
SSTATE_DIR, and then it would do_package_write_rpm from the data
of sstate-eglibc-xxx_package.tgz, but the objdump can find that the
binary file depends on the special version of libgcc, and it would
write the data( libgcc1 >= 4.6.0) to eglibc.spec, but the current
version of libgcc is 4.5.1, so there would be dependencies error when
do_rootfs.

I don't know how to fix this, maybe we should not mirror the tarball of
sstate-xxx_package.tgz(which is mirrored according to the DEPENDS) from the
SSTATE_DIR, but only mirror the tarball of sstate-xxx_deploy-rpm.tgz(which
is mirrored according to the RDEPENDS, the RDEPENDS is what the binary
rpm package really cares), the similar to ipk and deb.

-- 
Thanks

Robert

Re: bug 1169 eglibc doesn't depend on gcc version correctly

[Richard Purdie]

On Wed, 2011-08-24 at 14:35 +0800, Robert Yang wrote:
> Hi experts,
> 
> There is a bug 1169: eglibc doesn't depend on gcc version correctly,
> 
> The produce steps are:
> 
> 1) In the first build dir(e.g, build_1), edit conf/local.conf:
>     SSTATE_DIR = /path/to/share_sstate
> 
>     $ bitbake meta-toolchain
> 
> 2) In the second build dir(e.g, build_2), edit local.conf:
>     SSTATE_DIR = /path/to/share_sstate
>     SDKGCCVERSION="4.5.1"
>     GCCVERSION="4.5.1"
> 
>     $ bitbake meta-toolchain
> 
> Then we will notice the error:
> | error: Failed dependencies:
> |       libgcc1 >= 4.6.0 is needed by eglibc-utils-2.13-r1+svnr14157.armv5te
> 
> The reason is a little complicated:
> As we can see that eglibc's RDPENDS should have 'libgcc', but eglibc's
> DEPENDS(not RDEPENDS) can't have libgcc, otherwise there would be loop
> dependencies(since libgcc already DEPENDS on eglibc), this causes
> eglibc.do_package can't detect that the version of libgcc or gcc
> has been changed from 4.6 to 4.5.1, so it would mirror the
> sstate-eglibc-xxx_package.tgz(which is stored by gcc 4.6) from the
> SSTATE_DIR, and then it would do_package_write_rpm from the data
> of sstate-eglibc-xxx_package.tgz, but the objdump can find that the
> binary file depends on the special version of libgcc, and it would
> write the data( libgcc1 >= 4.6.0) to eglibc.spec, but the current
> version of libgcc is 4.5.1, so there would be dependencies error when
> do_rootfs.
> 
> I don't know how to fix this, maybe we should not mirror the tarball of
> sstate-xxx_package.tgz(which is mirrored according to the DEPENDS) from the
> SSTATE_DIR, but only mirror the tarball of sstate-xxx_deploy-rpm.tgz(which
> is mirrored according to the RDEPENDS, the RDEPENDS is what the binary
> rpm package really cares), the similar to ipk and deb.

The sstate checksum of the sstate-eglibc-xxx_package.tgz package should
have changed when the gcc version changed, such that it would repackage
(based on updated data). I think the problem is that in the sstate code,
we've assumed the toolchain is special and can change:

BB_HASHTASK_WHITELIST ?= "(.*-cross$|.*-native$|.*-cross-initial$|.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"

and this may be a sign we should reconsider this. Alternatively we could
hiighlight we simply don't support gcc version going backwards...

Cheers,

Richard