libwidevinecdm.so requires libgcc_s.so even if Firefox does not
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
People
(Reporter: juippis, Assigned: jld)
Details
Steps to reproduce:
Try to play DRM content on a system with no GCC installed.
This seems to be a problem in systems with no GCC installed. Like Alpine Linux, or Gentoo with systemwide llvm/clang.
Downstream bug with some additional information:
https://bugs.gentoo.org/910309
$ scanelf -n libwidevinecdm.so
TYPE NEEDED FILE
ET_DYN libdl.so.2,libpthread.so.0,libm.so.6,libgcc_s.so.1,libc.so.6,ld-linux-x86-64.so.2 libwidevinecdm.so
Actual results:
WidevineCdm plugin crashes.
Expected results:
DRM content should play.
|
||
Comment 1•10 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
In my case (as the reporter of the downstream gentoo bug), I do have GCC and glibc installed, so there's possibly another part to this as well, in that when used on a system compiled with clang (but with libgcc_s.so.1 available), the sandbox prevents widevine from accessing libgcc_s.so.1 - when using MOZ_DISABLE_GMP_SANDBOX=1 this seems to work OK.
I can confirm that on a system predominantly linked using libc++ rather than glibc, adding the solution mentioned in #1356038 works (adding a dlopen call in SetMediaPluginSandbox).
(In reply to Jim Mathies [:jimm] from comment #4)
Sounds sandbox related. Gian-Carlo, thoughts?
I think it's multiple issues - on a system with glibc installed it's sandbox related and so can be fixed with the dlopen call as per the linked bug, but on a system without glibc and just libc++ widevine won't work at all, this would need a rebuild of widevine on a libc++ system, and since widevine is proprietary would need google to produce a build.
|
||
Comment 6•10 months ago
•
|
||
on a system with glibc installed it's sandbox related and so can be fixed with the dlopen call as per the linked bug,
You mean https://bugzilla.mozilla.org/show_bug.cgi?id=1356038#c12 I assume (the other bug is about macOS X, which works completely differently even if it seems superficially similar), specifically you hit the case outlined here https://bugzilla.mozilla.org/show_bug.cgi?id=1356038#c4 but not due to static linking, but due to a libc mismatch.
I think it's likely fine to take your patch (https://910309.bugs.gentoo.org/attachment.cgi?id=865541) upstream.
|
|
||
Updated•10 months ago
|
(In reply to Gian-Carlo Pascutto [:gcp] from comment #6)
on a system with glibc installed it's sandbox related and so can be fixed with the dlopen call as per the linked bug,
You mean https://bugzilla.mozilla.org/show_bug.cgi?id=1356038#c12 I assume (the other bug is about macOS X, which works completely differently even if it seems superficially similar), specifically you hit the case outlined here https://bugzilla.mozilla.org/show_bug.cgi?id=1356038#c4 but not due to static linking, but due to a libc mismatch.
I think it's likely fine to take your patch (https://910309.bugs.gentoo.org/attachment.cgi?id=865541) upstream.
Yes, sorry! I mean the 135608 bug, rather than the Mac OS X one. Happy for the patch to be used upstream.
|
Assignee | |
Comment 8•10 months ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #6)
I think it's likely fine to take your patch (https://910309.bugs.gentoo.org/attachment.cgi?id=865541) upstream.
We already have some library preloading for plugins, and we've previously added some libraries that Widevine needed and Firefox itself might not, so this could added there instead.
Description
•