From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: sstate reuse for -native, -cross across different host glibc version, how to make it work?
Date: Fri, 23 Mar 2012 15:13:31 +0000 [thread overview]
Message-ID: <1332515611.9740.428.camel@ted> (raw)
In-Reply-To: <CABcZANm-V7QSXhdu2aUj6G-oekaHpdNohVxFRywrwmTB_GoXGQ@mail.gmail.com>
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@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?
Cheers,
Richard
next prev parent reply other threads:[~2012-03-23 15:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-23 12:22 sstate reuse for -native, -cross across different host glibc version, how to make it work? Koen Kooi
2012-03-23 12:41 ` Richard Purdie
2012-03-23 14:12 ` Chris Larson
2012-03-23 15:13 ` Richard Purdie [this message]
2012-03-23 15:22 ` Chris Larson
2012-03-23 16:35 ` McClintock Matthew-B29882
2012-03-23 17:13 ` Tom Rini
2012-03-24 18:23 ` McClintock Matthew-B29882
2012-03-25 19:52 ` Chris Larson
2012-03-26 3:31 ` Khem Raj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1332515611.9740.428.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox