Control: tag -1 fixed-upstream Hi Carlos,
On 17.08.2015 21: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. Apologies for the inaccuracies in my explanation. I'm not that familiar with glibc internals. ;) > 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. > > Without Alex's fixes the implementation is limited, by a heuristic, to > a limited number of libraries with STATIC_TLS, and after Alex's fixes > (available in glibc 2.22) the limit is "You may load as many > STATIC_TLS libraries as long as you have static image space for all of > them" (which is a much higher arbitrary limit). So this is already fixed upstream. Great! In that case I don't mind working around that in ffmpeg until glibc 2.22 reaches sid. Best regards, Andreas
