Hi, On 16.08.2015 17:12, Andreas Henriksson wrote: > Thanks for your interest in this issue.
You're welcome. > On Sun, Jul 26, 2015 at 09:35:16PM +0200, Andreas Cadhalpun wrote: >> Control: severity 793641 important > [...] > > I'd like to start out with questioning this.... gstreamer1.0-libav > is completely unuable now, breaking very popular programs like totem. > Severity should in my opinion be grave. The severity had been normal originally so I increased it. I didn't chose grave, because this bug doesn't make glibc unusable. You can adjust the severity, if you think that is appropriate, but arguing about bug severity is usually not helpful. > [...] >> The link [1] provided there is quite helpful. > [...] >> 1: https://bugzilla.redhat.com/show_bug.cgi?id=1124987 > > It indeed is, and I'd like to point out comment #22: > > " > For the record it is not a glibc bug. It is a defect in the loaded > libraries, they should not require TLS. Fundamentally it's a defect > that we allowed developers to build shared libraries with static TLS > in the first place. > " > > https://bugzilla.redhat.com/show_bug.cgi?id=1124987#c22 Then let me also point out form comment #15: "> 108 /lib64/libgomp.so.1 - OK. May use STATIC_TLS, it's part of the implementation. Language runtime support for gomp shared across all programs." "> 0 /lib64/libcrypt.so.1 > 0 /lib64/libm.so.6 > 0 /lib64/libnsl.so.1 > 0 /lib64/libnss_files.so.2 > 0 /lib64/libpthread.so.0 > 0 /lib64/libresolv.so.2 > 0 /lib64/librt.so.1 > 0 /lib64/libutil.so.1 - OK, all part of the implementation (glibc)." So it's not a bug in libgomp and libresolv and hence can only be fixed in glibc. > No matter if this is a bug in glibc or not, ffmpeg maintainers should > take any 'temporary' measures at hand to ensure usability and not expect > changes to be done on a whim to critical system components like glibc. I had hoped that one of the glibc maintainers would comment on this bug, before we resort to workarounds. > This breakage has persisted way too long now. However, surprisingly few people complained about it... > If there are no other option, As I wrote the other option would be to work around this bug by not linking ffmpeg against some external libraries. Can you confirm that removing --enable-libsoxr from ffmpeg's debian/rules avoids this problem? If not, also removing --enable-libssh should work. > maybe it's time to start planning transitioning back to libav No. > 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. > Speaking to #debian-multimedia there doesn't seem to > be much interest in dealing with the breakage caused by the ffmpeg > transition right now. Since the bug is in glibc, only the glibc maintainers can fix it. Best regards, Andreas