]> code.ossystems Code Review - openembedded-core.git/commit
uninative: Handle futex hangs caused by glibc version mismatches
authorRichard Purdie <richard.purdie@linuxfoundation.org>
Fri, 8 Dec 2017 15:14:31 +0000 (15:14 +0000)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Sat, 9 Dec 2017 11:05:56 +0000 (11:05 +0000)
commit6b149a88cd33c65c7f306f785f4d24ee2909809c
treed92edac84e18572b6299700527820d18a40b97b4
parent0a6be26cb8de71b74fd0520cd24185ed99a5911f
uninative: Handle futex hangs caused by glibc version mismatches

We've been seeing hangs in smart on the autobuilders where it hangs in
pthread futex calls. It appears to happen when some components are
installed from sstate (which use the interpreter from uninative)
and other components are built natively (and use the host's interpreter).

Its primarily affecting software which uses shared memory with futexs in
for locking purposes (which bdb does called from librpm from smart).

This isn't an issue in pyro and rocko and beyond since they use recipe
specific sysroots which included a change to always change to the
uninative interpreter. We could backport those changes but they're
fairly invasive changes to the sstate code. This patch is a more
minimal change which ensures binaries are always using the uninative
interpreter regardless of whether they're built locally or installed
from sstate.

This is only an issue if you're using an sstate mirror and hosts
with a variety of different libc versions. It has only become an issue
on recent libc versions where there was clearly some forwards compatibility
issue introduced.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta/classes/uninative.bbclass