Segfaults on startup in various Gnome3 programs, e.g. cheese, some areas of gnome-control-center (e.g. Users). The problem stems from pw_init() ambiguously exported from both libpipewire.so and libutil.so. The libgstpipewire.so's plugin_init() calls pw_init() to initialize libpipewire. Since libgstpipewire.so links to both libpipewire.so and libutil.so, on my system it happens to call pw_init exported from libutil.so instead of the libpipewire.so's one. Both exports take two pointers as parameters and the SIGSEGV occurs later on when effectively uninitialized libpipewire starts being used. The backtrace when SIGSEGV actually occurs looks like: Thread 1 received signal SIGSEGV, Segmentation fault. Address not mapped to object. 0x0000000801477aa6 in strspn () from /lib/libc.so.7 (gdb) bt #0 0x0000000801477aa6 in strspn () at /lib/libc.so.7 #1 0x000000081a612569 in pw_split_walk () at /usr/local/lib/libpipewire-0.3.so.0 #2 0x000000081a5f7c51 in pw_load_spa_handle () at /usr/local/lib/libpipewire-0.3.so.0 #3 0x000000081a5e9147 in pw_loop_new () at /usr/local/lib/libpipewire-0.3.so.0 ...
The problem is understood, but I have no idea how to fix this properly.
Why does libgstpipewire.so needs to link to libutil.so, which services it require from the library? If libutil.so is indeed required, I suspect there is no way around other than: - either ensure that -lpipewire is specified before -lutil - or rename pw_util symbol into something else with #define for libpipewire and its consumers. This would be a local patch that we have to keep forever. There might be yet another solution, but it is relatively complicated. pipewire port might provide so called filter library over libutil.so, which re-export everything except conflicting symbols. Then link against this filter and not the genuine libutil.so.
libpipewire itself doesn't have libutil dependency. In case of `cheese` program, it's /usr/local/lib/libgstreamer-1.0.so.0 which does: /usr/local/lib/libgstreamer-1.0.so.0: libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x801000000) libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x8007be000) libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x801059000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x8007c4000) libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8007d3000) libm.so.5 => /lib/libm.so.5 (0x801194000) librt.so.1 => /usr/lib/librt.so.1 (0x8007ed000) libdl.so.1 => /usr/lib/libdl.so.1 (0x8007f6000) libthr.so.3 => /lib/libthr.so.3 (0x8011c7000) libc.so.7 => /lib/libc.so.7 (0x800263000) libffi.so.7 => /usr/local/lib/libffi.so.7 (0x8011f4000) libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x8011ff000) libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x8012a3000) libutil.so.9 => /lib/libutil.so.9 (0x8013a2000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8013ba000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x8013d3000) libz.so.6 => /lib/libz.so.6 (0x8013ff000) libmd.so.6 => /lib/libmd.so.6 (0x80141b000) Specifying right lib search order -la -lb etc would probably solve the issue, but libpipewire is not linked to libgstreamer at compile time, it's probably dlopen'ed by libgstpipewire plugin at runtime. Eliminating libutil from gstreamer's dependencies might be the way to go. Here's full backtrace of `cheese` at time of SEGV. Note, the pw_init was already called at this point: (gdb) bt #0 0x0000000801477aa6 in strspn () at /lib/libc.so.7 #1 0x000000084acb9569 in pw_split_walk () at /usr/local/lib/libpipewire-0.3.so.0 #2 0x000000084ac9ec51 in pw_load_spa_handle () at /usr/local/lib/libpipewire-0.3.so.0 #3 0x000000084ac90147 in pw_loop_new () at /usr/local/lib/libpipewire-0.3.so.0 #4 0x000000084acb8610 in () at /usr/local/lib/libpipewire-0.3.so.0 #5 0x000000084ac19e0f in () at /usr/local/lib/gstreamer-1.0/libgstpipewire.so #6 0x000000080120dd1a in gst_device_provider_start () at /usr/local/lib/libgstreamer-1.0.so.0 #7 0x000000080120c118 in gst_device_monitor_start () at /usr/local/lib/libgstreamer-1.0.so.0 #8 0x00000008002a18e0 in () at /usr/local/lib/libcheese.so.8 #9 0x0000000800d806e7 in g_initable_new_valist () at /usr/local/lib/libgio-2.0.so.0 #10 0x0000000800d805fe in g_initable_new () at /usr/local/lib/libgio-2.0.so.0 #11 0x000000080029d5aa in cheese_camera_setup () at /usr/local/lib/libcheese.so.8 #12 0x000000000022fb98 in () #13 0x000000000023138e in () #14 0x0000000800e8c3cd in () at /usr/local/lib/libgobject-2.0.so.0 #15 0x0000000800ea2596 in g_signal_emit_valist () at /usr/local/lib/libgobject-2.0.so.0 #16 0x0000000800ea2ff6 in g_signal_emit () at /usr/local/lib/libgobject-2.0.so.0 #17 0x00000000002302ad in () #18 0x0000000800d87ca6 in () at /usr/local/lib/libgio-2.0.so.0 #19 0x0000000800e8c3cd in () at /usr/local/lib/libgobject-2.0.so.0 #20 0x0000000800ea2596 in g_signal_emit_valist () at /usr/local/lib/libgobject-2.0.so.0 #21 0x0000000800ea2ff6 in g_signal_emit () at /usr/local/lib/libgobject-2.0.so.0 #22 0x0000000800de3f74 in () at /usr/local/lib/libgio-2.0.so.0 #23 0x0000000800de5d6f in () at /usr/local/lib/libgio-2.0.so.0 #24 0x0000000800de3cea in g_application_run () at /usr/local/lib/libgio-2.0.so.0 #25 0x000000000023246e in () #26 0x000000000022f640 in () #27 0x000000000022f540 in () #28 0x0000000000000000 in ()
Btw, even if libgstreamer no longer depends on libutil, there are others like `gnome-control-center` program, which depend on /usr/local/lib/libgstreamer-1.0.so.0 /usr/lib/libprocstat.so.1 /usr/local/lib/libsecret-1.so.0 And each of those individually depend on libutil, or at least specify -lutil at compile time...
Created attachment 229547 [details] Patch Upstream provided following patch. Drop it into `multimedia/pipewire/files` directory, rebuild the port and check if it fixes the issue.
Yes, this fixed the issue! `cheese` now works fine in gnome-shell environment. Also the 'Users' and other sections of gnome-control-center now work too, except I still have an issue with 'Power' section, but that was there before and looks like configuration issue (possibly related to schema 'org.gnome.settings-daemon.plugins.power' does not contain a key named 'power-saver-profile-on-low-battery'). Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=8691df3a5142ab9381d6f1c9af2377dd4696e084 commit 8691df3a5142ab9381d6f1c9af2377dd4696e084 Author: Gleb Popov <arrowd@FreeBSD.org> AuthorDate: 2021-11-20 16:47:48 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2021-11-20 16:49:30 +0000 multimedia/pipewire: Add a patch to fix ambguous function name issue. PR: 259621 multimedia/pipewire/Makefile | 1 + .../files/patch-src_pipewire_pipewire_init (new) | 67 ++++++++++++++++++++++ 2 files changed, 68 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e92349ca0c3d9b0ccdb1e5d40b3b536b39f56890 commit e92349ca0c3d9b0ccdb1e5d40b3b536b39f56890 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2021-11-20 22:05:10 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2021-11-20 22:41:23 +0000 multimedia/pipewire: force rebuild consumers after 8691df3a5142 ABI has changed: pw_{,de}init -> pipewire_{,de}init. As PipeWire support is often runtime-optional the breakage maybe hard to notice. ERROR kooha::backend::screencast_portal > Error from screencast call: Zbus(MethodError(OwnedInterfaceName(InterfaceName(Str("org.freedesktop.DBus.Error.UnknownMethod"))), Some("No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop"), Msg { type: Error, sender: UniqueName(Str(":1.397")), reply-serial: 18, body: Signature: [ s (115), ] })) ld-elf.so.1: /usr/local/libexec/xdg-desktop-portal-wlr: Undefined symbol "pw_init" PR: 259621 audio/musicpd/Makefile | 1 + deskutils/xdg-desktop-portal/Makefile | 2 +- net-im/telegram-desktop/Makefile | 1 + net-im/tg_owt/Makefile | 2 +- x11-wm/gamescope/Makefile | 1 + x11-wm/mutter/Makefile | 1 + x11/xdg-desktop-portal-wlr/Makefile | 1 + 7 files changed, 7 insertions(+), 2 deletions(-)
A commit in branch 2021Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=add690556ebdda0de00204c24f0de911de82b1dd commit add690556ebdda0de00204c24f0de911de82b1dd Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2021-11-20 22:05:10 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2021-11-20 22:43:42 +0000 multimedia/pipewire: force rebuild consumers after 8691df3a5142 ABI has changed: pw_{,de}init -> pipewire_{,de}init. As PipeWire support is often runtime-optional the breakage maybe hard to notice. ERROR kooha::backend::screencast_portal > Error from screencast call: Zbus(MethodError(OwnedInterfaceName(InterfaceName(Str("org.freedesktop.DBus.Error.UnknownMethod"))), Some("No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop"), Msg { type: Error, sender: UniqueName(Str(":1.397")), reply-serial: 18, body: Signature: [ s (115), ] })) ld-elf.so.1: /usr/local/libexec/xdg-desktop-portal-wlr: Undefined symbol "pw_init" PR: 259621 (cherry picked from commit e92349ca0c3d9b0ccdb1e5d40b3b536b39f56890) deskutils/xdg-desktop-portal/Makefile | 2 +- net-im/telegram-desktop/Makefile | 2 +- net-im/tg_owt/Makefile | 2 +- x11-wm/gamescope/Makefile | 1 + x11-wm/mutter/Makefile | 1 + x11/xdg-desktop-portal-wlr/Makefile | 2 +- 6 files changed, 6 insertions(+), 4 deletions(-)
A commit in branch 2021Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=031836e2ec8b0463dec91f282f9cdfde38281008 commit 031836e2ec8b0463dec91f282f9cdfde38281008 Author: Gleb Popov <arrowd@FreeBSD.org> AuthorDate: 2021-11-20 16:47:48 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2021-11-20 21:31:15 +0000 multimedia/pipewire: Add a patch to fix ambguous function name issue. PR: 259621 (cherry picked from commit 8691df3a5142ab9381d6f1c9af2377dd4696e084) multimedia/pipewire/Makefile | 2 +- .../files/patch-src_pipewire_pipewire_init (new) | 67 ++++++++++++++++++++++ 2 files changed, 68 insertions(+), 1 deletion(-)
Backported to /quarterly because this also fixed multimedia/kooha crash after pressing Record button. Kooha itself links against libutil and libutil is linked via some of Kooha dependencies (gstreamer1, gstreamer1-plugins, gtk4, graphene, libadwaita, pango, harfbuzz, gdk-pixbuf2). * thread #1, name = 'kooha', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x000031afd911e52b libc.so.7`strspn(s=0x0000000000000000, charset=":") at strspn.c:51:5 48 u_long tbl[(UCHAR_MAX + 1) / LONG_BIT]; 49 int idx; 50 -> 51 if(*s == '\0') 52 return (0); 53 54 #if LONG_BIT == 64 /* always better to unroll on 64-bit architectures */ (lldb) bt * thread #1, name = 'kooha', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) * frame #0: 0x000031afd911e52b libc.so.7`strspn(s=0x0000000000000000, charset=":") at strspn.c:51:5 frame #1: 0x000031b05b93b923 libpipewire-0.3.so.0`pw_split_walk(str=0x0000000000000000, delimiter=":", len=0x00007fffffcc9978, state=0x00007fffffcc9980) at utils.c:47:7 frame #2: 0x000031b05b91316c libpipewire-0.3.so.0`pw_load_spa_handle(lib=0x0000000000000000, factory_name="support.system", info=0x0000000000000000, n_support=0, support=0x00007fffffcc9a70) at pipewire.c:273:14 frame #3: 0x000031b05b8fba4f libpipewire-0.3.so.0`pw_loop_new(props=0x0000000000000000) at loop.c:79:24 frame #4: 0x000031b05b939fa8 libpipewire-0.3.so.0`loop_new(loop=0x0000000000000000, name="pipewire-main-loop", props=0x0000000000000000) at thread-loop.c:124:10 frame #5: 0x000031b05b939ee1 libpipewire-0.3.so.0`pw_thread_loop_new(name="pipewire-main-loop", props=0x0000000000000000) at thread-loop.c:186:9 frame #6: 0x000031b05cceb8d2 libgstpipewire.so`make_core(fd=19) at gstpipewirecore.c:73:16 frame #7: 0x000031b05cceb71e libgstpipewire.so`gst_pipewire_core_get(fd=19) at gstpipewirecore.c:147:12 frame #8: 0x000031b05ccf8eea libgstpipewire.so`gst_pipewire_src_open(pwsrc=0x000031b04bfb18e0) at gstpipewiresrc.c:1112:17 frame #9: 0x000031b05ccf71e9 libgstpipewire.so`gst_pipewire_src_change_state(element=0x000031b04bfb18e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstpipewiresrc.c:1216:12 frame #10: 0x000031afd3ac4743 libgstreamer-1.0.so.0`gst_element_change_state(element=0x000031b04bfb18e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstelement.c:2952:11 frame #11: 0x000031afd3ac7015 libgstreamer-1.0.so.0`gst_element_set_state_func(element=0x000031b04bfb18e0, state=GST_STATE_READY) at gstelement.c:2906:9 frame #12: 0x000031afd3ac3dc2 libgstreamer-1.0.so.0`gst_element_set_state(element=0x000031b04bfb18e0, state=GST_STATE_READY) at gstelement.c:2807:14 frame #13: 0x000031afd3a8d819 libgstreamer-1.0.so.0`gst_bin_element_set_state(bin=0x000031b04c0321e0, element=0x000031b04bfb18e0, base_time=0, start_time=0, current=GST_STATE_NULL, next=GST_STATE_READY) at gstbin.c:2605:9 frame #14: 0x000031afd3a87722 libgstreamer-1.0.so.0`gst_bin_change_state_func(element=0x000031b04c0321e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstbin.c:2947:15 frame #15: 0x000031afd3b04687 libgstreamer-1.0.so.0`gst_pipeline_change_state(element=0x000031b04c0321e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstpipeline.c:504:12 frame #16: 0x000031afd3ac4743 libgstreamer-1.0.so.0`gst_element_change_state(element=0x000031b04c0321e0, transition=GST_STATE_CHANGE_NULL_TO_READY) at gstelement.c:2952:11 frame #17: 0x000031afd3ac7015 libgstreamer-1.0.so.0`gst_element_set_state_func(element=0x000031b04c0321e0, state=GST_STATE_PLAYING) at gstelement.c:2906:9 frame #18: 0x000031afd3ac3dc2 libgstreamer-1.0.so.0`gst_element_set_state(element=0x000031b04c0321e0, state=GST_STATE_PLAYING) at gstelement.c:2807:14 frame #19: 0x000031a7d072d525 kooha`_$LT$kooha..backend..recorder..imp..Recorder$u20$as$u20$glib..subclass..object..ObjectImpl$GT$::set_property::h0b4cccf7efe128ca + 325 frame #20: 0x000031a7d073a583 kooha`glib::subclass::object::set_property::hce3789fc1cf614d5 + 83 frame #21: 0x000031afd1c70968 libgobject-2.0.so.0`object_set_property(object=0x000031b00916f390, pspec=0x000031b002c04130, value=0x00007fffffccab28, nqueue=0x000031b0091bf080) at gobject.c:1571:7 frame #22: 0x000031afd1c70441 libgobject-2.0.so.0`g_object_setv(object=0x000031b00916f390, n_properties=1, names=0x00007fffffccaab0, values=0x00007fffffccab28) at gobject.c:2410:7 frame #23: 0x000031afd1c71af8 libgobject-2.0.so.0`g_object_set_property(object=0x000031b00916f390, property_name="state", value=0x00007fffffccab28) at gobject.c:2698:3 frame #24: 0x000031a7d06ed424 kooha`kooha::backend::recorder::Recorder::set_state::h137c331c577ded7b + 324 frame #25: 0x000031a7d06ef4c0 kooha`kooha::backend::recorder::Recorder::start::h3c61ef928fec92fd + 256 frame #26: 0x000031a7d06e305e kooha`_$LT$T$u20$as$u20$glib..object..ObjectExt$GT$::connect_local::_$u7b$$u7b$closure$u7d$$u7d$::hc10a5da41e6a503a + 110 frame #27: 0x000031a7d06e61cd kooha`glib::closure::Closure::new_unsafe::marshal::h2ccecf936b317c6a (.llvm.4490151282539723725) + 29 frame #28: 0x000031afd1c64ed5 libgobject-2.0.so.0`g_closure_invoke(closure=0x000031b002d802a0, return_value=0x0000000000000000, n_param_values=1, param_values=0x00007fffffccb2d0, invocation_hint=0x00007fffffccb0d8) at gclosure.c:830:7 frame #29: 0x000031afd1c8660b libgobject-2.0.so.0`signal_emit_unlocked_R(node=0x000031b006ba87a0, detail=0, instance=0x000031b009170d60, emission_return=0x0000000000000000, instance_and_params=0x00007fffffccb2d0) at gsignal.c:3742:8 frame #30: 0x000031afd1c85e23 libgobject-2.0.so.0`g_signal_emitv(instance_and_params=0x00007fffffccb2d0, signal_id=108, detail=0, return_value=0x0000000000000000) at gsignal.c:3227:3 frame #31: 0x000031a7d06a86eb kooha`_$LT$T$u20$as$u20$glib..object..ObjectExt$GT$::emit_by_name::h365c55bac4488a61 + 843 frame #32: 0x000031a7d06b29f8 kooha`kooha::backend::timer::Timer::start::h1d03a2d580432504 + 248 frame #33: 0x000031a7d06e2adc kooha`_$LT$T$u20$as$u20$glib..object..ObjectExt$GT$::connect_local::_$u7b$$u7b$closure$u7d$$u7d$::h64cd76f875e384b4 + 124 frame #34: 0x000031a7d06e65bd kooha`glib::closure::Closure::new_unsafe::marshal::h4fa0bed22a871b6a (.llvm.4490151282539723725) + 29 frame #35: 0x000031afd1c64ed5 libgobject-2.0.so.0`g_closure_invoke(closure=0x000031b002d6ffe0, return_value=0x0000000000000000, n_param_values=1, param_values=0x00007fffffccbb20, invocation_hint=0x00007fffffccb928) at gclosure.c:830:7 frame #36: 0x000031afd1c8660b libgobject-2.0.so.0`signal_emit_unlocked_R(node=0x000031b006ba8b60, detail=0, instance=0x000031b00916f390, emission_return=0x0000000000000000, instance_and_params=0x00007fffffccbb20) at gsignal.c:3742:8 frame #37: 0x000031afd1c85e23 libgobject-2.0.so.0`g_signal_emitv(instance_and_params=0x00007fffffccbb20, signal_id=106, detail=0, return_value=0x0000000000000000) at gsignal.c:3227:3 frame #38: 0x000031a7d06e9748 kooha`_$LT$T$u20$as$u20$glib..object..ObjectExt$GT$::emit_by_name::hf22667b62549d04f (.llvm.3901114416550982646) + 856 frame #39: 0x000031a7d06ed92a kooha`kooha::backend::recorder::Recorder::build_pipeline::hef9f114f35e10421 + 666 frame #40: 0x000031a7d06ceec6 kooha`_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::hdc0f29e8cfbe351f + 6902 frame #41: 0x000031a7d08acf99 kooha`glib::main_context::_$LT$impl$u20$glib..auto..main_context..MainContext$GT$::with_thread_default::haf36bc4ef3fd9e2a + 137 frame #42: 0x000031a7d08a7d6a kooha`glib::main_context_futures::TaskSource::dispatch::h626774632a35a388 (.llvm.1230265796533566852) + 58 frame #43: 0x000031afd2a2a825 libglib-2.0.so.0`g_main_dispatch(context=0x000031b002c206c0) at gmain.c:3381:27 frame #44: 0x000031afd2a2a660 libglib-2.0.so.0`g_main_context_dispatch(context=0x000031b002c206c0) at gmain.c:4099:7 frame #45: 0x000031afd2a2abb0 libglib-2.0.so.0`g_main_context_iterate(context=0x000031b002c206c0, block=1, dispatch=1, self=0x000031b002c47a40) at gmain.c:4175:5 frame #46: 0x000031afd2a2ac53 libglib-2.0.so.0`g_main_context_iteration(context=0x000031b002c206c0, may_block=1) at gmain.c:4240:12 frame #47: 0x000031afd6ee720d libgio-2.0.so.0`g_application_run(application=0x000031b006bd9150, argc=1, argv=0x000031b002d7e040) at gapplication.c:2569:7 frame #48: 0x000031a7d06e8fb1 kooha`kooha::application::Application::run::hb55283e0eed45f72 + 769 frame #49: 0x000031a7d06dedbd kooha`kooha::main::hf8757a3b2068848d + 381 frame #50: 0x000031a7d07377f3 kooha`std::sys_common::backtrace::__rust_begin_short_backtrace::h3eb75b04487bf6a3 + 3 frame #51: 0x000031a7d0725249 kooha`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h5c5a57569b040be7 (.llvm.17216673041266972443) + 9 frame #52: 0x000031a7d08c4981 kooha`std::rt::lang_start_internal::hed5448c7acecc2aa + 33 frame #53: 0x000031a7d06deff2 kooha`main + 34 frame #54: 0x000031a7d066c146 kooha`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:73:7
(In reply to Jan Beich from comment #11) > Kooha itself links against libutil and libutil is linked via some of Kooha dependencies... Err, libutil is pulled via libglib-2.0 (from devel/glib20) which Kooha directly depends on and pulls via other dependencies.
IMO, somebody (upstream?) should bump dso version.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f0a3f8e66866cb022f8405a4a2772836a1f06de7 commit f0a3f8e66866cb022f8405a4a2772836a1f06de7 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2021-11-20 23:41:56 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2021-11-21 02:39:17 +0000 www/firefox: unbreak PipeWire support after 8691df3a5142 libpipewire is used on demand via dlopen(). Currently, only enabled for WebRTC getUserMedia (screen capture) under Wayland. https://searchfox.org/mozilla-release/rev/e2929d8cad28/third_party/libwebrtc/webrtc/modules/desktop_capture/screen_capturer_linux.cc#28 PR: 259621 mail/thunderbird/Makefile | 2 +- mail/thunderbird/files/patch-pipewire_init (new) | 73 ++++++++++++++++++++++++ www/firefox-esr/Makefile | 2 +- www/firefox-esr/files/patch-pipewire_init (new) | 73 ++++++++++++++++++++++++ www/firefox/Makefile | 1 + www/firefox/files/patch-pipewire_init (new) | 73 ++++++++++++++++++++++++ 6 files changed, 222 insertions(+), 2 deletions(-)
A commit in branch 2021Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=da2987316783339d1d74b9252e4f87233781d0c9 commit da2987316783339d1d74b9252e4f87233781d0c9 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2021-11-20 23:41:56 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2021-11-21 05:10:30 +0000 www/firefox: unbreak PipeWire support after 8691df3a5142 libpipewire is used on demand via dlopen(). Currently, only enabled for WebRTC getUserMedia (screen capture) under Wayland. https://searchfox.org/mozilla-release/rev/e2929d8cad28/third_party/libwebrtc/webrtc/modules/desktop_capture/screen_capturer_linux.cc#28 PR: 259621 (cherry picked from commit f0a3f8e66866cb022f8405a4a2772836a1f06de7) mail/thunderbird/Makefile | 2 +- mail/thunderbird/files/patch-pipewire_init (new) | 73 ++++++++++++++++++++++++ www/firefox-esr/Makefile | 2 +- www/firefox-esr/files/patch-pipewire_init (new) | 73 ++++++++++++++++++++++++ www/firefox/Makefile | 1 + www/firefox/files/patch-pipewire_init (new) | 73 ++++++++++++++++++++++++ 6 files changed, 222 insertions(+), 2 deletions(-)
Ouch, sorry for committing this without bumping consumers. /me puts on the largest pointy hat he has.