bug 1724900 breaks non-pipewire builds ?
Categories
(Core :: WebRTC, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox-esr115 | --- | unaffected |
firefox114 | --- | unaffected |
firefox115 | --- | unaffected |
firefox116 | --- | fixed |
People
(Reporter: gaston, Assigned: jgrulich)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
we don't have pipewire on OpenBSD, and while working on bug 1837918 (unbreak build on OpenBSD after webrtc 112 update) i stumbled upon a new linking failure:
107:38.49 ld.lld: error: undefined hidden symbol: webrtc::CameraPortal::CameraPortal(webrtc::CameraPortal::PortalNotifier*)
it looks like it might be a regression from bug 1724900.
Reporter | ||
Updated•1 year ago
|
Comment 1•1 year ago
|
||
Set release status flags based on info from the regressing bug 1724900
Reporter | ||
Comment 2•1 year ago
|
||
looking 5mn about this failure, the caller/instanciator for CameraPortal
should be within #ifdef WEBRTC_USE_PIPEWIRE
(but that seems to be the case in https://searchfox.org/mozilla-central/source/dom/media/systemservices/CamerasParent.cpp#1198), or non-pipewire builds should also build & link camera_portal.cc
, it was apparently only added to pipewire builds in https://phabricator.services.mozilla.com/D179192
sorry, wont be able to dig more... see http://buildbot.rhaalovely.net/nine/#/builders/3/builds/1730 for the complete failure log.
107:08.75 ld.lld: error: undefined hidden symbol: webrtc::CameraPortal::CameraPortal(webrtc::CameraPortal::PortalNotifier*)
107:08.75 >>> referenced by unique_ptr.h:728 (/usr/include/c++/v1/__memory/unique_ptr.h:728)
107:08.75 >>> /build/obj/buildslave/mozilla-central/toolkit/library/build/../../../dom/media/systemservices/Unified_cpp_systemservices1.o:(mozilla::CameraPortalImpl::Start())
107:08.76 ld.lld: error: undefined hidden symbol: webrtc::CameraPortal::~CameraPortal()
107:08.76 >>> referenced by unique_ptr.h:57 (/usr/include/c++/v1/__memory/unique_ptr.h:57)
107:08.76 >>> /build/obj/buildslave/mozilla-central/toolkit/library/build/../../../dom/media/systemservices/Unified_cpp_systemservices1.o:(mozilla::CameraPortalImpl::Start())
107:08.76 >>> referenced by unique_ptr.h:57 (/usr/include/c++/v1/__memory/unique_ptr.h:57)
107:08.76 >>> /build/obj/buildslave/mozilla-central/toolkit/library/build/../../../dom/media/systemservices/Unified_cpp_systemservices1.o:(mozilla::CameraPortalImpl::~CameraPortalImpl())
107:08.76 >>> referenced by unique_ptr.h:57 (/usr/include/c++/v1/__memory/unique_ptr.h:57)
107:08.76 >>> /build/obj/buildslave/mozilla-central/toolkit/library/build/../../../dom/media/systemservices/Unified_cpp_systemservices1.o:(mozilla::CameraPortalImpl::~CameraPortalImpl())
107:08.76 ld.lld: error: undefined hidden symbol: webrtc::CameraPortal::Start()
107:08.76 >>> referenced by pipewire_camera_impl.cc:16 (/build/buildslave-amd64/mozilla-central-amd64/build/dom/media/systemservices/video_engine/pipewire_camera_impl.cc:16)
107:08.76 >>> /build/obj/buildslave/mozilla-central/toolkit/library/build/../../../dom/media/systemservices/Unified_cpp_systemservices1.o:(mozilla::CameraPortalImpl::Start())
107:09.93 clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
Assignee | ||
Comment 3•1 year ago
|
||
Using gtk shouldn't be the only precondition to enable PipeWire support
as we can use gtk on platforms where PipeWire is still not available. We
currently only build PipeWire support in WebRTC for Linux so make these
conditions in sync and avoid relying solely on having gtk.
Updated•1 year ago
|
Assignee | ||
Comment 4•1 year ago
|
||
Hi, can you please test and verify the attached patch fixes the issue for you?
Reporter | ||
Comment 5•1 year ago
|
||
error from http://buildbot.rhaalovely.net/nine/#/builders/3/builds/1731
2:36.16 ==============================
2:36.16 FATAL ERROR PROCESSING MOZBUILD FILE
2:36.16 ==============================
2:36.16
2:36.16 The error occurred while processing the following file:
2:36.16
2:36.16 /build/buildslave-amd64/mozilla-central-amd64/build/dom/media/webrtc/third_party_build/webrtc.mozbuild
2:36.16
2:36.16 This file was included as part of processing:
2:36.16
2:36.16 /build/buildslave-amd64/mozilla-central-amd64/build/ipc/glue/moz.build
2:36.16
2:36.16 The underlying problem is a Python syntax error on line 24:
2:36.16
2:36.16 if CONFIG['CPU_ARCH'] == 'x86' or CONFIG['CPU_ARCH'] == 'x86_64' or
not sure it should fail like that, as afaict this if block is a valid python construct ?
will retry ditching the if to make sure non-pipewire builds are okay.
Reporter | ||
Comment 6•1 year ago
|
||
http://buildbot.rhaalovely.net/nine/#/builders/3/builds/1732 succeeded linking libxul.so, so the idea behind the patch (eg defining WEBRTC_USE_PIPEWIRE only on linux instead of for all gtk platforms) is right. Don't know about the previous failure though, and it also seems to me that FreeBSD might have (some?) pipewire support - jan might know more.
Assignee | ||
Comment 7•1 year ago
|
||
(In reply to Landry Breuil (:gaston) from comment #5)
error from http://buildbot.rhaalovely.net/nine/#/builders/3/builds/1731
2:36.16 ============================== 2:36.16 FATAL ERROR PROCESSING MOZBUILD FILE 2:36.16 ============================== 2:36.16 2:36.16 The error occurred while processing the following file: 2:36.16 2:36.16 /build/buildslave-amd64/mozilla-central-amd64/build/dom/media/webrtc/third_party_build/webrtc.mozbuild 2:36.16 2:36.16 This file was included as part of processing: 2:36.16 2:36.16 /build/buildslave-amd64/mozilla-central-amd64/build/ipc/glue/moz.build 2:36.16 2:36.16 The underlying problem is a Python syntax error on line 24: 2:36.16 2:36.16 if CONFIG['CPU_ARCH'] == 'x86' or CONFIG['CPU_ARCH'] == 'x86_64' or
not sure it should fail like that, as afaict this if block is a valid python construct ?
will retry ditching the if to make sure non-pipewire builds are okay.
Can you try now?
Reporter | ||
Comment 8•1 year ago
|
||
with the latest version of the diff adding the \ to the continuation of the conditions (eg https://phabricator.services.mozilla.com/D181434?id=732832), mach configure
succeeded here. Thanks !
http://buildbot.rhaalovely.net/nine/#/builders/3/builds/1735 should have your diff as a local patch (and the one from bug 1837918)
(In reply to Landry Breuil (:gaston) from comment #6)
it also seems to me that FreeBSD might have (some?) pipewire support - jan might know more.
PipeWire works fine on FreeBSD for both video (screensharing on Wayland like wlroots) and audio (via ALSA -> OSS plugin) but not in Firefox >= 103 or Chromium. Sorry, I've stopped contributing to Firefox due to bug 1536716, bug 1654407, burnout and can't test camera in PipeWire or Firefox due to lacking such a device on my desktop.
Reporter | ||
Comment 10•1 year ago
|
||
(In reply to Jan Beich from comment #9)
(In reply to Landry Breuil (:gaston) from comment #6)
it also seems to me that FreeBSD might have (some?) pipewire support - jan might know more.
PipeWire works fine on FreeBSD for both video (screensharing on Wayland like wlroots) and audio (via ALSA -> OSS plugin) but not in Firefox >= 103 or Chromium.
thanks for the detailed feedback ! Who should i cc for the forthcoming FreeBSD work, cmt@ ?
Sorry, I've stopped contributing to Firefox due to bug 1536716, bug 1654407, burnout and can't test camera in PipeWire or Firefox due to lacking such a device on my desktop.
Oof... sorry for that, i can relate. Taking a step back can help against burnout, i hope you'll get better rsn !
Reporter | ||
Updated•1 year ago
|
Comment 11•1 year ago
|
||
(In reply to Landry Breuil (:gaston) from comment #10)
Not that I have any plan about pipewire - my audio/video equipment is tied up on my work setup (which is decidedly non-BSD) and I haven't really tried any of that stuff on BSD for a long time (you can maintain or use it, but you won't have time for both). Also, running firefox beta is such a PITA (solving captchas like a pro) that I avoid most web stuff beyond basic news reading.
Reporter | ||
Comment 12•1 year ago
|
||
i see https://phabricator.services.mozilla.com/D181434 is accepted, can it land before the next m-c->m-b merge ? i still have the diff in my queue.. thanks !
Comment 13•1 year ago
|
||
I have queued it, thanks for confirming that it works.
Comment 14•1 year ago
|
||
Comment 15•1 year ago
|
||
bugherder |
Comment 16•1 year ago
|
||
Set release status flags based on info from the regressing bug 1724900
Description
•