On 2015-08-17 15:04, Carlos O'Donell wrote: > On Sun, Aug 16, 2015 at 12:48 PM, Andreas Cadhalpun > <andreas.cadhal...@googlemail.com> wrote: > >> until there's a better tested and working way to transition > >> to ffmpeg? > > > > This really doesn't have that much to do with the transition to ffmpeg. > > Any other library that (indirectly) links against sufficiently many > > STATIC_TLS using ones and is used in some plugin is also affected. > > > > Note that there are currently 14 STATIC_TLS slots and gst-libav uses 6, > > while it used 4 previously. It is a mere coincidence that this increase > > causes totem to hit the arbitrary limit in glibc. > > The math can't be done that easily, it's actually a heuristic, but > pretend it works this way for the sake of this discussion. > > The only immediate solution is for debian's glibc to increase > DTV_SURPLUS to 32 or higher. This is exactly what I did for Fedora. > > The other alternative is to backport Alex's fixes for Sourceware bugs > BZ #17090, BZ #17620, BZ #17621, BZ #17628, which corrects the > heuristics behind DTV_SURPLUS which prevent the loading of STATIC_TLS.
I have backported these patches to 2.21. Unfortunately they now cause nptl/tst-cancel24-static to fail on at least armhf, armel, mips and mipsel. The binary segfaults. According to the wiki [1], the failure seems to be a known issue in the 2.22 release, though its cause was marked as unknown. Do you know by chance if the problem has been fixed or addressed in the meantime? Thanks, Aurelien [1] https://sourceware.org/glibc/wiki/Release/2.22 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net