[OE-core] sstate reuse for -native, -cross across different host glibc version, how to make it work?

[Chris Larson]

On Fri, Mar 23, 2012 at 8:13 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Fri, 2012-03-23 at 07:12 -0700, Chris Larson wrote:
>> On Fri, Mar 23, 2012 at 5:41 AM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>> > On Fri, 2012-03-23 at 13:22 +0100, Koen Kooi wrote:
>> >> I turned on sstate mirroring for angstrom recently and I'm getting
>> >> reports of build failures due to missing GLIBC_2.14 symbols:
>> >>
>> >> arm-angstrom-linux-gnueabi-gcc: /lib/x86_64-linux-gnu/libc.so.6:
>> >> version `GLIBC_2.14' not found (required by
>> >> arm-angstrom-linux-gnueabi-gcc)
>> >>
>> >> The sstate tarballs are built on a Fedora16 VM and the breakage occurs
>> >> when it being used on systems with an older c library (e.g. debian).
>> >> To get rid of this problem there are multiple options, but I think the
>> >> 2 most obvious are:
>> >>
>> >> 1) inject host distroname and distroversion into the checksums
>> >> 2) build everything against a native libc
>> >>
>> > 3) Use an older version on the VM which is the oldest distro you plan to
>> > build against.
>> >
>> >> Would it be appropriate to get 1) into oe-core before the branchpoint?
>> >
>> > We've talked about this and its been on the "to fix" list but nobody has
>> > got around to it. Its hard as we need to come up with something that
>> > isn't going to kill performance of the checksum calculations. A cat
>> > operation on a few files for each checksum for example isn't
>> > appropriate. We may need to do something at the bitbake level as there
>> > is also the issue of checksuming local files such as those in file://
>> > urls and including that in the sstate checksums.
>> >
>> > So whilst I'd love to see fixes for these and they are bugfixes, they're
>> > going to have to be well written patches and its late in cycle for
>> > invasive changes :(.
>>
>> At Mentor, right now, I'm using a ConfigParsed event handler to run
>> lsb_release and inject the DISTRO/DISTRO_VERSION into the metadata,
>> which I then use vardeps to ensure get into the appropriate
>> signatures. Not perfect, but gets the job done.
>
> Are those patches available anywhere we can look at?

Not yet. I'll see about emailing them to the list for review this afternoon.
-- 
Christopher Larson