On 2015-06-15 12:36, Marc Kleine-Budde wrote: > On 06/15/2015 11:49 AM, Aurelien Jarno wrote: > >> Given that stable has kernel 3.16 the probably easiest solution would be > >> to bump the dependency to >= 3.16?! > > > > No, it's not a solution, just a workaround. For stretch we will switch > > the minimum kernel to 3.2, that is the one from wheezy. We have always > > done such a way so that people can use chroots with different > > distributions, and we still have complaints that we don't allow old > > enough kernel versions. > > > > The solution would be to backport the upstream fix, but I can't find it > > in current git, nor in the bug report. Could you please point it to me? > > This bug was caused by glibc commit (during glibc-2.20 development): > > 47c5adebd2c8 Correct robust mutex / > PI futex kernel assumptions (bug 9894). > > Instead of applying your proposed patch > (https://sourceware.org/bugzilla/attachment.cgi?id=3778&action=diff) to > enable the PI and robust mutex on kernels >= 2.6.28, PI and robust > mutexes were completely disabled for ARM. > > Later, during the glibc-2.21 development this commit: > > 03d41216fe09 arm: Re-enable PI futex support for > ARM kernels >= 3.14.3 > > was added. So you need --enable-kernel=3.14.3 for glibc-2.21 for PI and > robust mutexes. > > This means glibc-2.20 doesn't support PI/robust mutex on ARM at all, > glibc-2.21 needs --enable-kernel=3.14.3. That's not correct. The __ASSUME_* defines tells that the feature is there unconditionally. When they are not defined, the code should probe for the feature before using it, and if it is not present, fallback to a compatibility code. I guess there is a bug in the probe or the compatibility code, and it's what we want to fix. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: Digital signature