[meta] BSD libwebrtc update issues 2H2020
Categories
(Core :: WebRTC, task, P2)
Tracking
()
People
(Reporter: ng, Assigned: gaston)
References
Details
(Keywords: meta)
Attachments
(8 files, 4 obsolete files)
|
1.57 KB,
patch
|
ng
:
review+
|
Details | Diff | Splinter Review |
|
2.99 MB,
patch
|
ng
:
review+
|
Details | Diff | Splinter Review |
|
9.96 KB,
patch
|
ng
:
review+
|
Details | Diff | Splinter Review |
|
809.50 KB,
text/plain
|
ng
:
review+
|
Details |
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta-
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta-
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta-
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta-
|
Details | Review |
This bug is for collecting the BSD specific issues that arise while updating libwebrtc.
|
Assignee | |
Comment 1•3 years ago
|
||
available to test on OpenBSD, since large changes/updates tend to break often on tier3 platforms :) is there a moz-phab command to pull a patch stack applying to m-c ? i see that the meta bug 1654112 has no target, is there a timeframe for this ?
|
|
Assignee | |
Comment 2•2 years ago
|
||
fwiw it seems the webrtc update broke BSDs, as 96.0b1 fails to build, at least for me on OpenBSD:
third_party/libwebrtc/api/audio_codecs/L16/audio_decoder_L16_gn/Unified_cpp_audio_decoder_L16_gn0.o
/usr/obj/ports/firefox-96.0beta1/bin/c++ -std=gnu++17 -o Unified_cpp_audio_decoder_L16_gn0.o -c -I/usr/obj/ports/firefox-96.0beta1/build-amd64/dist/stl_wrappers -I/usr/obj/ports/firefox-96.0beta1/build-amd64/dist/system_wrappers -include /usr/obj/ports/firefox-96.0beta1/firefox-96.0/config/gcc_hidden.h -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fstack-clash-protection -DNDEBUG -DTRIMMED=1 -DABSL_ALLOCATOR_NOTHROW=1 -DRTC_ENABLE_VP9 -DWEBRTC_ENABLE_PROTOBUF=0 -DWEBRTC_LIBRARY_IMPL -DWEBRTC_MOZILLA_BUILD -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DNVALGRIND -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -I/usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/api/audio_codecs/L16/audio_decoder_L16_gn -I/usr/obj/ports/firefox-96.0beta1/build-amd64/third_party/libwebrtc/api/audio_codecs/L16/audio_decoder_L16_gn -I/usr/obj/ports/firefox-96.0beta1/build-amd64/ipc/ipdl/_ipdlheaders -I/usr/obj/ports/firefox-96.0beta1/firefox-96.0/ipc/chromium/src -I/usr/obj/ports/firefox-96.0beta1/firefox-96.0/ipc/glue -I/usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc -I/usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/third_party/abseil-cpp -I/usr/obj/ports/firefox-96.0beta1/firefox-96.0/tools/profiler/public -I/usr/obj/ports/firefox-96.0beta1/build-amd64/dist/include -DMOZILLA_CLIENT -include /usr/obj/ports/firefox-96.0beta1/build-amd64/mozilla-config.h -Qunused-arguments -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wdeprecated-this-capture -Wempty-body -Wformat-type-confusion -Wignored-qualifiers -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wno-error=tautological-type-limit-compare -Wunreachable-code -Wunreachable-code-return -Wno-invalid-offsetof -Wclass-varargs -Wempty-init-stmt -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wno-range-loop-analysis -Wc++2a-compat -Wcomma -Wenum-compare-conditional -Wimplicit-fallthrough -Wstring-conversion -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-erro
r=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wno-error=deprecated-copy -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-psabi -Wno-unknown-warning-option -fno-sized-deallocation -fno-aligned-new -O2 -pipe -g -fno-exceptions -fno-strict-aliasing -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -O2 -pipe -g -fomit-frame-pointer -funwind-tables -fexperimental-new-pass-manager -MD -MP -MF .deps/Unified_cpp_audio_decoder_L16_gn0.o.pp Unified_cpp_audio_decoder_L16_gn0.cpp In file included from Unified_cpp_aec3_factory_gn0.cpp:2: In file included from /usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/api/audio/echo_canceller3_factory.cc:14: In file included from /usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/modules/audio_processing/aec3/echo_canceller3.h:30: In file included from /usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/rtc_base/race_checker.h:15: /usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/rtc_base/platform_thread_types.h:47:1: error: unknown type name 'PlatformThreadId' PlatformThreadId CurrentThreadId(); ^ /usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/rtc_base/platform_thread_types.h:52:1: error: unknown type name 'PlatformThreadRef' PlatformThreadRef CurrentThreadRef(); ^ /usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/rtc_base/platform_thread_types.h:55:29: error: unknown type name 'PlatformThreadRef' bool IsThreadRefEqual(const PlatformThreadRef& a, const PlatformThreadRef& b); ^
/usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/rtc_base/platform_thread_types.h:55:57: error: unknown type name 'PlatformThreadRef'
bool IsThreadRefEqual(const PlatformThreadRef& a, const PlatformThreadRef& b);
^
In file included from Unified_cpp_aec3_factory_gn0.cpp:2:
In file included from /usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/api/audio/echo_canceller3_factory.cc:14:
In file included from /usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/modules/audio_processing/aec3/echo_canceller3.h:30:
/usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/rtc_base/race_checker.h:37:20: error: unknown type name 'PlatformThreadRef'
mutable volatile PlatformThreadRef accessing_thread_;
^
In file included from Unified_cpp_aec3_factory_gn0.cpp:2:
/usr/obj/ports/firefox-96.0beta1/firefox-96.0/third_party/libwebrtc/api/audio/echo_canceller3_factory.cc:27:10: error: no viable conversion from returned value of type 'unique_ptr<webrtc::EchoCanceller3>' to funct
ion return type 'unique_ptr<webrtc::EchoControl>'
return std::make_unique<EchoCanceller3>(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/memory:2320:28: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'typename __unique_if<EchoCanceller3>::__unique_single' (aka 'unique_ptr<webrtc:
:EchoCanceller3>') to 'const std::__1::unique_ptr<webrtc::EchoControl, std::__1::default_delete<webrtc::EchoControl>> &' for 1st argument
class _LIBCPP_TEMPLATE_VIS unique_ptr {
looking at third_party/libwebrtc/rtc_base/platform_thread_types.h id say WEBRTC_POSIX isnt defined everywhere where it should be for *BSD ?
|
|
Assignee | |
Comment 3•2 years ago
|
||
https://searchfox.org/mozilla-central/search?q=WEBRTC_POSIX&path= seems to show that many moz.build files define WEBRTC_POSIX for android/darwin/linux and not for BSDs, so i think those moz.build files should be regenerated with proper GN config for BSD.
|
|
Assignee | |
Comment 4•2 years ago
|
||
hi guys, since you all worked hard on bug #1654112, any idea how to unbreak/unblock us tier3 ? thanks !
|
Reporter | |
Comment 5•2 years ago
|
||
Landry, we are happy to help. The instructions to generate those build files are in the README.md in the folder: https://searchfox.org/mozilla-central/source/dom/media/webrtc/third_party_build/gn-configs/README.md . If you have a Firefox dev environment setup you should be able to follow the directions there. I suspect the the generation script https://searchfox.org/mozilla-central/source/dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh#74 will need a little tweaking for BSD, but that should be pretty straight forward, and we will happily accept patches. You should create at least one debug (the *_true_* files) and one opt (the *_false_* files) mozconfig. I would guess that one could copy the linux mozconfigs as a starting point.
I think there should be at least 3 commits:
- adds the BSD mozconfig files in gn-configs
- adds the generated BSD json files in gn-configs
- adds the changes to the
third_party/libwebrtc/**/moz.buildfiles
If any changes are needed to files inthird_party/libwebrtcthose changes should go in their own patch. It is possible for example that some of the BUILD.gn files might require alteration.
If that isn't clear, if you get stuck, or if you need any more assistance, please aggressively use needinfo to mfroman and myself. Full disclaimer, neither of us has worked on BSD, so this is just supposing that everything should work as it has on other platforms.
note: because the third_party/libwebrtc/**/moz.build files are generated (using the aforementioned script), we don't accept hand edits to those files.
|
|
Assignee | |
Comment 6•2 years ago
|
||
my understanding after looking is that all the work that had been done in bug #807492 and then destroyed and redone in bug #1437670 is now lost. <sadface.jpg>.
And i'm not sure at all the gclient thing works on BSD :)
so i've tried following https://searchfox.org/mozilla-central/source/dom/media/webrtc/third_party_build/gn-configs/README.md and here's what i did:
[13:39] c64:~/src/ $git clone https://chromium.googlesource.com/chromium/tools/depot_tools
[13:39] c64:~/src/ $cd depot_tools/
[13:50] c64:~/src/depot_tools/ $git checkout e7d1862b155ac3ccbef72c4d70629b5c88ffcb32
[13:52] c64:~/src/depot_tools/ $export DEPOT_TOOLS=`pwd`
[13:48] c64:~/src/ $git clone https://github.com/mozilla/libwebrtc moz-libwebrtc
[13:51] c64:~/src/ $cd moz-libwebrtc/
[13:51] c64:~/src/moz-libwebrtc/ $ git checkout mozilla-modifications-rel86
[13:52] c64:~/src/moz-libwebrtc/ $export MOZ_LIBWEBRTC=`pwd`
[13:53] c64:~/src/m-c/dom/media/webrtc/third_party_build/gn-configs $cp x64_True_x64_{linux,openbsd}.mozconfig
[13:53] c64:~/src/m-c/dom/media/webrtc/third_party_build/gn-configs $cp x64_False_x64_{linux,openbsd}.mozconfig
[13:53] c64:~/src/m-c/dom/media/webrtc/third_party_build/gn-configs $cp x64_True_arm64_{linux,openbsd}.mozconfig
[13:53] c64:~/src/m-c/dom/media/webrtc/third_party_build/gn-configs $cp x64_False_arm64_{linux,openbsd}.mozconfig
[13:54] c64:~/src/m-c/dom/media/webrtc/third_party_build/gn-configs/ $hg diff generate-gn-build-files.sh
--- a/dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh
+++ b/dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh
@@ -87,16 +87,18 @@ if [ "x$SYS_NAME" = "xDarwin" ]; then
CONFIGS="x64_False_arm64_mac x64_True_arm64_mac x64_False_x64_mac x64_True_x64_mac"
IS_DARWIN=1
elif [ "x$SYS_NAME" = "xMINGW32_NT-6.2" ]; then
export DEPOT_TOOLS_WIN_TOOLCHAIN=0
CONFIGS="x64_True_arm64_win x64_False_arm64_win"
CONFIGS="$CONFIGS x64_True_x64_win x64_False_x64_win"
CONFIGS="$CONFIGS x64_True_x86_win x64_False_x86_win"
IS_WIN=1
+elif [ "x$SYS_NAME" = "xOpenBSD" ]; then
+ CONFIGS="x64_False_arm64_openbsd x64_True_arm64_openbsd x64_False_x64_openbsd x64_True_x64_openbsd"
else
[13:55] c64:~/src/moz-libwebrtc/ $export PATH=$DEPOT_TOOLS:$PATH ; export DEPOT_TOOLS_UPDATE=0 ; export DEPOT_TOOLS_WIN_TOOLCHAIN=0
[13:55] c64:~/src/moz-libwebrtc/ $gclient config https://github.com/mozilla/libwebrtc
CIPD not supported on openbsd
/home/landry/src/depot_tools/bootstrap_python3: ligne 32: bootstrap-3.8.0.chromium.8_bin/python3/bin/python3: No such file or directory
cat: /home/landry/src/depot_tools/python3_bin_reldir.txt: No such file or directory
/home/landry/src/depot_tools/vpython3: ligne 52: /home/landry/src/depot_tools/.cipd_bin/vpython3: No such file or directory
[13:56] c64:~/src/moz-libwebrtc/ $python3.9 ../depot_tools/gclient.py config https://github.com/mozilla/libwebrtc
[13:57] c64:~/src/moz-libwebrtc/ $python3.9 ../depot_tools/gclient.py sync -D --force --reset --with_branch_heads
libwebrtc (ERROR)
----------------------------------------
[0:00:00] Started.
[0:00:00]
Traceback (most recent call last):
File "/home/landry/src/depot_tools/gclient_scm.py", line 1043, in _Clone
self._Run(clone_cmd, options, cwd=self._root_dir, retry=True,
File "/home/landry/src/depot_tools/gclient_scm.py", line 1411, in _Run
gclient_utils.CheckCallAndFilter(cmd, env=env, **kwargs)
File "/home/landry/src/depot_tools/gclient_utils.py", line 592, in CheckCallAndFilter
os_type = GetMacWinAixOrLinux()
File "/home/landry/src/depot_tools/gclient_utils.py", line 751, in GetMacWinAixOrLinux
raise Error('Unknown platform: ' + sys.platform)
gclient_utils.Error: 1> Unknown platform: openbsd7
----------------------------------------
Error: 1> Unknown platform: openbsd7
### patches gclient_utils.py so that it thinks we're linux
[13:57] c64:~/src/moz-libwebrtc/ $python3.9 ../depot_tools/gclient.py sync -D --force --reset --with_branch_heads
...
'host_os': _detect_host_os(),
File "/home/landry/src/moz-libwebrtc/../depot_tools/gclient.py", line 1298, in _detect_host_os
return _PLATFORM_MAPPING[sys.platform]
KeyError: 'openbsd7'
### patches gclient.py ...
[14:01] c64:~/src/moz-libwebrtc/ $python3.9 ../depot_tools/gclient.py sync -D --force --reset --with_branch_heads
...
Syncing projects: 23% (10/42) src/buildtools/third_party/libc++/trunk
/home: write failed, file system is full
sorry, i think that's just asking for too much. ~/src/moz-libwebrtc/ is more than 3g and hasnt even finished fetching everything, and i have no idea if it'd work in the end, or if it's actually used. that gclient thing is just a glorified forkbomb-generator-disk-filling-contraption
so i've tried going anyway:
[14:08] c64:~/src/m-c/ $bash ./dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh
MOZ_LIBWEBRTC is /home/landry/src/moz-libwebrtc
DEPOT_TOOLS is /home/landry/src/depot_tools
There are modified files in the checkout. Cowardly aborting!
M dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh
## comments out the stupid exit 1
[14:13] c64:~/src/m-c/ $ bash ./dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh [0/9346]
MOZ_LIBWEBRTC is /home/landry/src/moz-libwebrtc
DEPOT_TOOLS is /home/landry/src/depot_tools
There are modified files in the checkout. Cowardly aborting!
M dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh
CONFIG_DIR is dom/media/webrtc/third_party_build/gn-configs
Building gn json file for x64_False_arm64_openbsd
Using MOZCONFIG=dom/media/webrtc/third_party_build/gn-configs/x64_False_arm64_openbsd.mozconfig
created virtual environment CPython3.9.9.final.0-64 in 205ms
creator CPython3Posix(dest=/home/landry/.mozbuild/srcdirs/m-c-4d1cbf8c0e13/_virtualenvs/mach, clear=False, no_vcs_ignore=False, global=False)
activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator
Collecting glean-sdk==40.0.0
Using cached glean_sdk-40.0.0-cp36-abi3-openbsd_7_0_amd64.whl
Collecting cffi>=1.13.0
Using cached cffi-1.15.0-cp39-cp39-openbsd_7_0_amd64.whl
Collecting glean-parser==3.6.0
Using cached glean_parser-3.6.0-py3-none-any.whl (80 kB)
Requirement already satisfied: jsonschema<4,>=3.0.2 in ./third_party/python/jsonschema (from glean-parser==3.6.0->glean-sdk==40.0.0) (3.2.0)
Requirement already satisfied: Click>=7 in ./third_party/python/click (from glean-parser==3.6.0->glean-sdk==40.0.0) (7.1.2)
Requirement already satisfied: PyYAML>=5.3.1 in ./third_party/python/PyYAML/lib3 (from glean-parser==3.6.0->glean-sdk==40.0.0) (5.4.1)
Requirement already satisfied: Jinja2>=2.10.1 in ./third_party/python/Jinja2 (from glean-parser==3.6.0->glean-sdk==40.0.0) (2.11.3)
Requirement already satisfied: yamllint>=1.18.0 in ./third_party/python/yamllint (from glean-parser==3.6.0->glean-sdk==40.0.0) (1.23.0)
Requirement already satisfied: appdirs>=1.4 in ./third_party/python/appdirs (from glean-parser==3.6.0->glean-sdk==40.0.0) (1.4.4)
Requirement already satisfied: diskcache>=4 in ./third_party/python/diskcache (from glean-parser==3.6.0->glean-sdk==40.0.0) (4.1.0)
Collecting pycparser
Using cached pycparser-2.21-py2.py3-none-any.whl (118 kB)
Requirement already satisfied: MarkupSafe>=0.23 in ./third_party/python/MarkupSafe/src (from Jinja2>=2.10.1->glean-parser==3.6.0->glean-sdk==40.0.0) (1.1.1)
Requirement already satisfied: pyrsistent>=0.14.0 in ./third_party/python/pyrsistent (from jsonschema<4,>=3.0.2->glean-parser==3.6.0->glean-sdk==40.0.0) (0.16.0)
Requirement already satisfied: attrs>=17.4.0 in ./third_party/python/attrs (from jsonschema<4,>=3.0.2->glean-parser==3.6.0->glean-sdk==40.0.0) (19.1.0)
Requirement already satisfied: setuptools in ./third_party/python/setuptools (from jsonschema<4,>=3.0.2->glean-parser==3.6.0->glean-sdk==40.0.0) (51.2.0)
Requirement already satisfied: six>=1.11.0 in ./third_party/python/six (from jsonschema<4,>=3.0.2->glean-parser==3.6.0->glean-sdk==40.0.0) (1.13.0)
Requirement already satisfied: pathspec>=0.5.3 in ./third_party/python/pathspec (from yamllint>=1.18.0->glean-parser==3.6.0->glean-sdk==40.0.0) (0.9.0)
Installing collected packages: pycparser, glean-parser, cffi, glean-sdk
Successfully installed cffi-1.15.0 glean-parser-3.6.0 glean-sdk-40.0.0 pycparser-2.21
Collecting psutil<=5.8.0,>=5.4.2
Using cached psutil-5.8.0-cp39-cp39-openbsd_7_0_amd64.whl
Installing collected packages: psutil
Successfully installed psutil-5.8.0
Collecting zstandard<=0.16.0,>=0.11.1
Using cached zstandard-0.16.0-cp39-cp39-openbsd_7_0_amd64.whl
Installing collected packages: zstandard
Successfully installed zstandard-0.16.0
created virtual environment CPython3.9.9.final.0-64 in 404ms
creator CPython3Posix(dest=/home/landry/src/m-c/obj-x64_False_arm64_linux/_virtualenvs/build, clear=False, no_vcs_ignore=False, global=False)
activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator
0:06.30 /home/landry/src/m-c/obj-x64_False_arm64_linux/_virtualenvs/build/bin/python /home/landry/src/m-c/configure.py
....
0:27.12 checking the target C compiler works... no
0:27.13 DEBUG: Creating `/tmp/conftest.59mdb6vo.c` with content:
0:27.13 DEBUG: | int
0:27.13 DEBUG: | main(void)
0:27.13 DEBUG: | {
0:27.13 DEBUG: |
0:27.13 DEBUG: | ;
0:27.13 DEBUG: | return 0;
0:27.13 DEBUG: | }
0:27.13 DEBUG: Executing: `/usr/bin/clang -std=gnu99 --target=aarch64-openbsd7.0 /tmp/conftest.59mdb6vo.c -c`
0:27.13 DEBUG: The command returned non-zero exit status 1.
0:27.13 DEBUG: Its error output was:
0:27.13 DEBUG: | error: unable to create target: 'No available targets are compatible with triple "aarch64-unknown-openbsd7.0"'
0:27.13 DEBUG: | 1 error generated.
0:27.13 ERROR: Failed compiling a simple C source with the target C compiler
Error running mach:
['configure']
at that point i'm going to back off to keep my sanity, and i might look at it again someday ( i suppose i need to put more options into the mozconfigs), but that's just ... insane. as any build system/contraption imagined by mozilla :)
|
|
Assignee | |
Comment 7•2 years ago
|
||
for a single config, this fails later on anyway:
0:12.61 Reading file: /home/landry/src/m-c/dom/media/webrtc/third_party_build/moz.build
Running "/home/landry/src/depot_tools/gn gen /home/landry/src/m-c/obj-x64_False_x64_openbsd/dom/media/webrtc/third_party_build/../../../../third_party/libwebrtc/gn-output --args=is_debug=false target_os="openbsd" host_cpu="x64" target_cpu="x64" --ide=json"
gn.py: Could not find gn executable at: /home/landry/src/m-c/third_party/libwebrtc/buildtools/linux64/gn
Traceback (most recent call last):
File "/home/landry/src/m-c/obj-x64_False_x64_openbsd/config.status", line 896, in <module>
config_status(**args)
File "/home/landry/src/m-c/python/mozbuild/mozbuild/config_status.py", line 177, in config_status
the_backend.consume(definitions)
File "/home/landry/src/m-c/python/mozbuild/mozbuild/backend/base.py", line 132, in consume
if not self.consume_object(obj) and not isinstance(self, PartialBackend):
File "/home/landry/src/m-c/python/mozbuild/mozbuild/gn_processor.py", line 609, in consume_object
generate_gn_config(
File "/home/landry/src/m-c/python/mozbuild/mozbuild/gn_processor.py", line 582, in generate_gn_config
subprocess.check_call(gen_args, cwd=srcdir, stderr=subprocess.STDOUT)
File "/usr/local/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/home/landry/src/depot_tools/gn', 'gen', '/home/landry/src/m-c/obj-x64_False_x64_openbsd/dom/media/webrtc/third_party_build/../../../../third_party/libwebrtc/gn-output', '--args=is_debug=false target_os="openbsd" host_cpu="x64" target_cpu="x64"', '--ide=json']' returned non-zero exit status 2.
*** ERROR *** 1 157 Generation did not complete successfully!
after looking a bit, it looks like a gn binary is needed. sigh. guess i'll retry the steps i did in https://bugzilla.mozilla.org/show_bug.cgi?id=1437670#c16
|
|
Assignee | |
Comment 8•2 years ago
|
||
after building a gn binary, im greeted by:
Running "/home/landry/src/depot_tools/gn gen /home/landry/src/m-c/obj-x64_False_x64_openbsd/dom/media/webrtc/third_party_build/../../../../third_party/libwebrtc/gn-output --args=is_debug=false target_os="openbsd" host_cpu="x64" target_cpu="x64" --ide=json"
ERROR at //build/config/BUILDCONFIG.gn:217:5: Assertion failed.
assert(false, "Unsupported host_os: $host_os")
^-----
Unsupported host_os: openbsd
Traceback (most recent call last):
File "/home/landry/src/m-c/obj-x64_False_x64_openbsd/config.status", line 896, in <module>
config_status(**args)
File "/home/landry/src/m-c/python/mozbuild/mozbuild/config_status.py", line 177, in config_status
the_backend.consume(definitions)
File "/home/landry/src/m-c/python/mozbuild/mozbuild/backend/base.py", line 132, in consume
if not self.consume_object(obj) and not isinstance(self, PartialBackend):
File "/home/landry/src/m-c/python/mozbuild/mozbuild/gn_processor.py", line 609, in consume_object
generate_gn_config(
File "/home/landry/src/m-c/python/mozbuild/mozbuild/gn_processor.py", line 582, in generate_gn_config
subprocess.check_call(gen_args, cwd=srcdir, stderr=subprocess.STDOUT)
File "/usr/local/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
not that much surprised. i guess i'll have to reapply https://bugzilla.mozilla.org/attachment.cgi?id=8957838 to https://searchfox.org/mozilla-central/source/third_party/libwebrtc/build/config/BUILDCONFIG.gn
|
|
Assignee | |
Comment 9•2 years ago
|
||
Running "/home/landry/src/depot_tools/gn gen /home/landry/src/m-c/obj-x64_False_x64_openbsd/dom/media/webrtc/third_party_build/../../../../third_party/libwebrtc/gn-output --args=is_debug=false target_os="openbsd" host_cpu="x64" target_cpu="x64" --ide=json"
ERROR at //build/config/BUILDCONFIG.gn:310:1: Unknown function.
set_sources_assignment_filter(sources_assignment_filter)
the gift that keeps on giving.
the gn binary was built from configuring chromium 96.0.4664.93
|
|
Assignee | |
Comment 10•2 years ago
|
||
ccing freebsd folks as i guess they'll be interested in this ?
|
|
Assignee | |
Comment 11•2 years ago
|
||
i think i got something that modified the generated moz.build files with the openbsd specific bits. will check that m-c builds on top..
sadly i'll need someone with native arm64 access to generate the bits for arm64/aarch64 as rust on openbsd cant crosscompile and rustup isnt available.
|
|
Assignee | |
Comment 12•2 years ago
|
||
what feels wrong is that the moz.build files have OS_LIBS += [ "dl", "rt"] for CONFIG["OS_TARGET"] == "OpenBSD" but those libs dont exist on OpenBSD, so i guess it'll fail.
|
|
Assignee | |
Comment 13•2 years ago
|
||
the build failed early anyway..
66:36.24 In file included from Unified_cpp_ure_internal_impl_gn0.cpp:2:
66:36.24 In file included from /home/landry/src/m-c/third_party/libwebrtc/modules/video_capture/linux/device_info_linux.cc:11:
66:36.24 In file included from /home/landry/src/m-c/third_party/libwebrtc/modules/video_capture/linux/device_info_linux.h:19:
66:36.24 /usr/obj/m-c/dist/system_wrappers/sys/inotify.h:3:15: fatal error: 'sys/inotify.h' file not found
66:36.24 #include_next <sys/inotify.h>
66:36.25 ^~~~~~~~~~~~~~~
it's as is everything that had been done for *BSD support in previous bugs had been thrown away. depressing...
anyway, i'll sprinkle some #ifdef WEBRTC_LINUX here and there.
|
|
Assignee | |
Comment 14•2 years ago
|
||
a previous attempt tried to mock bsds as linuxes so i had this in moz.build files:
+if CONFIG["OS_TARGET"] == "OpenBSD":
+
+ DEFINES["CR_SYSROOT_HASH"] = "5f64b417e1018dcf8fcc81dc2714e0f264b9b911"
+ DEFINES["USE_AURA"] = "1"
+ DEFINES["USE_GLIB"] = "1"
+ DEFINES["USE_NSS_CERTS"] = "1"
+ DEFINES["USE_OZONE"] = "1"
+ DEFINES["USE_UDEV"] = True
+ DEFINES["USE_X11"] = "1"
+ DEFINES["WEBRTC_LINUX"] = True
+ DEFINES["WEBRTC_POSIX"] = True
+ DEFINES["_FILE_OFFSET_BITS"] = "64"
+ DEFINES["_GNU_SOURCE"] = True
+ DEFINES["_LARGEFILE64_SOURCE"] = True
+ DEFINES["_LARGEFILE_SOURCE"] = True
+ DEFINES["__STDC_CONSTANT_MACROS"] = True
+ DEFINES["__STDC_FORMAT_MACROS"] = True
+
+ OS_LIBS += [
+ "dl",
+ "rt"
+ ]
+
but i remembered that last time in bug #1437670 we used a plain is_bsd variable, so now i have something that sets this in moz.build files:
+if CONFIG["OS_TARGET"] == "OpenBSD":
+
+ DEFINES["USE_GLIB"] = "1"
+ DEFINES["WEBRTC_BSD"] = True
+ DEFINES["WEBRTC_POSIX"] = True
+ DEFINES["_FILE_OFFSET_BITS"] = "64"
+ DEFINES["_LARGEFILE64_SOURCE"] = True
+ DEFINES["_LARGEFILE_SOURCE"] = True
+ DEFINES["__STDC_CONSTANT_MACROS"] = True
+ DEFINES["__STDC_FORMAT_MACROS"] = True
now the question is, which of the missing USE_AURA / USE_NSS_CERTS / USE_OZONE / USE_X11 / USE_UDEV defines matters?
|
|
Assignee | |
Comment 15•2 years ago
|
||
note: i'm not going to put those on phabricator for two reasons:
- phabricator is user hostile for ppl not using daily. i've tried it, and gave up trying to be productive with it.
- those are wip patches
so, various changes:
- in
third_party/libwebrtc/build/config/ui.gnii had to workaround an assert, dunno if that's the right way, because i thinkuse_glibshould be true on bsd ?
-assert(!use_glib || (is_linux && !is_chromeos && !is_chromecast))
+assert(!use_glib || ((is_linux || is_bsd) && !is_chromeos && !is_chromecast))
-
in
third_party/libwebrtc/build/config/BUILDCONFIG.gni randomly added some openbsd checks, blindly trying what was done in the previous bug cf https://hg.mozilla.org/releases/mozilla-beta/rev/5d519dfb2238 and https://hg.mozilla.org/releases/mozilla-beta/rev/8a093b3af5b5 -
i guess https://searchfox.org/mozilla-central/source/third_party/libwebrtc/webrtc.gni#297 needs to be amended with
is_bsdif we want screen sharing to work -
commented out sources_assignment_filter lines in
third_party/libwebrtc/build/config/BUILDCONFIG.gnbecause gn choked on it ?
with all that, linking failed:
12:02.29 ld: error: undefined hidden symbol: webrtc::DesktopCaptureOptions::CreateDefault()
12:02.29 >>> referenced by Unified_cpp_systemservices0.cpp
12:02.29 >>> /usr/obj/m-c/toolkit/library/build/../../../dom/media/systemservices/Unified_cpp_systemservices0.o:(webrtc::DesktopCaptureImpl::Init())
12:02.29 >>> referenced by Unified_cpp_systemservices0.cpp
12:02.30 >>> /usr/obj/m-c/toolkit/library/build/../../../dom/media/systemservices/Unified_cpp_systemservices0.o:(webrtc::DesktopDeviceInfoImpl::InitializeWindowList())
12:02.30 ld: error: undefined hidden symbol: webrtc::DesktopCapturer::CreateScreenCapturer(webrtc::DesktopCaptureOptions const&)
12:02.30 >>> referenced by Unified_cpp_systemservices0.cpp
12:02.31 >>> /usr/obj/m-c/toolkit/library/build/../../../dom/media/systemservices/Unified_cpp_systemservices0.o:(webrtc::DesktopCaptureImpl::Init())
12:02.31 ld: error: undefined hidden symbol: webrtc::DesktopCapturer::CreateTabCapturer(webrtc::DesktopCaptureOptions const&)
12:02.31 >>> referenced by Unified_cpp_systemservices0.cpp
12:02.31 >>> /usr/obj/m-c/toolkit/library/build/../../../dom/media/systemservices/Unified_cpp_systemservices0.o:(webrtc::DesktopCaptureImpl::Init())
12:02.31 ld: error: undefined hidden symbol: webrtc::DesktopCapturer::CreateWindowCapturer(webrtc::DesktopCaptureOptions const&)
12:02.31 >>> referenced by Unified_cpp_systemservices0.cpp
...
etcetcetc
i'll retry with a clean build.
|
|
Assignee | |
Comment 16•2 years ago
|
||
here's the wip i have, which is probably deeply wrong in many aspects, but that's a start. mostly sending it so that it's saved somewhere. the /media/libyuv/libyuv/include/ changes to LOCAL_INCLUDES are probably wrong ? also OpenBSD doesnt have pipewire so i wonder how it'll go.
|
|
Assignee | |
Comment 17•2 years ago
|
||
for readability, here's the modified files in the diff that arent autogenerated:
- dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh adds the openbsd bits to the generation script
- third_party/libwebrtc/BUILD.gn (adds
WEBRTC_BSDdefine whenis_bsdis true) - third_party/libwebrtc/build/config/BUILDCONFIG.gn (adds
is_bsdand some uname checks) - third_party/libwebrtc/build/config/ui.gni (fixes the
use_glibGN assert) - third_party/libwebrtc/modules/video_capture/BUILD.gn (adds
is_bsdto the check adding linux files to the list of files being built for video capture) - third_party/libwebrtc/modules/video_capture/linux/device_info_linux.h (makes sure inotify.h is only included on linux)
- third_party/libwebrtc/rtc_base/platform_thread_types.cc - solves a cast error (
error: cast from pointer to smaller type 'rtc::PlatformThreadId') - third_party/libwebrtc/webrtc.gni adds
is_bsdtortc_desktop_capture_supported
would love general feedback on this horror show. afaict, the tree built (will redo a clean regen/build), i have yet to test runtime.
|
|
Assignee | |
Comment 18•2 years ago
|
||
with my patchset, i've been able to use https://www.webrtc-experiment.com/DetectRTC/ & https://www.webrtc-experiment.com/RecordRTC/ to test audio and webcam successfully. Trying screensharing with https://www.webrtc-experiment.com/getDisplayMedia/ i sortof managed to share a window capture with the page but i had a js alert after sharing with
Unable to capture your screen.
TypeError
screen.getTracks()[0].getCapabilities is not a function
button.onclick/<@https://www.webrtc-experiment.com/getDisplayMedia/:127:51
but i'm not sure its a firefox issue or website issue, as the behaviour/error was the same with nightly as with 95.0. Either way, that looks a bit promising :)
|
|
Assignee | |
Comment 19•2 years ago
|
||
|
|
Assignee | |
Comment 20•2 years ago
|
||
|
|
Assignee | |
Comment 21•2 years ago
|
||
this patch only has the relevant bits, not the autogenerated moz.build goo
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 22•2 years ago
|
||
fwiw some bits from bug #1376873 should be taken, along the fixes for bug #1706261 that were supposed to be reapplied in bug #1714115
|
|
Assignee | |
Comment 23•2 years ago
|
||
[Tracking Requested - why for this release]: FTBFS on Tier-3/BSD
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 24•2 years ago
|
||
Comment on attachment 9255254 [details] [diff] [review]
1654448-webrtc_bsd.diff
r+, with questions, and one requested minor change
|
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 25•2 years ago
|
||
Michael, do you mind having a look at the patch I reviewed as well?
|
|
Assignee | |
Comment 26•2 years ago
|
||
(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #24)
Comment on attachment 9255254 [details] [diff] [review]
1654448-webrtc_bsd.diffr+, with questions, and one requested minor change
which questions/requested change ? didnt see anything on splinter.. or you've pushed something to phabricator that isnt linked to this bug ?
ofc the commented out # exit 1 in generate-gn-build-files.sh and the commented out import("//build/config/deprecated_default_sources_assignment_filter.gni") chunk in BUILDCONFIG.gn arent meant for commit ..
whats the process to get the generated moz.build changes commited ? should they be regenerated on a tier-1 platform with the mozconfig/json files for *bsd imported/added ? from my understanding that wouldnt be possible without rustup.
now would also be the right time for freebsd folks to chime in too :)
|
|
Reporter | |
Comment 27•2 years ago
|
||
Comment on attachment 9255254 [details] [diff] [review] 1654448-webrtc_bsd.diff Review of attachment 9255254 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh @@ +65,5 @@ > hg purge > else > echo "There are modified files in the checkout. Cowardly aborting!" > echo "$MODIFIED_FILES" > +# exit 1 This should stay. I understand that it may be a bit annoying when you are having to repeatedly change things. @@ +93,5 @@ > CONFIGS="$CONFIGS x64_True_x86_win x64_False_x86_win" > IS_WIN=1 > +elif [ "x$SYS_NAME" = "xOpenBSD" ]; then > + CONFIGS="x64_False_x64_openbsd x64_True_x64_openbsd" > +# CONFIGS="$CONFIGS x64_False_arm64_openbsd x64_True_arm64_openbsd" If the intent is to defer doing the work for arm (which is fine) could you add a comment? ::: third_party/libwebrtc/build/config/BUILDCONFIG.gn @@ +306,5 @@ > # when all files that depend on the assignment have been converted to import > # the file directly. See https://crbug.com/1018739#c69. > > +#import("//build/config/deprecated_default_sources_assignment_filter.gni") > +#sources_assignment_filter = deprecated_default_sources_assignment_filter Note to MJF: this doesn't appear to exist upstream any more. I am ok with taking this as long the other platforms continue to generate correctly. ::: third_party/libwebrtc/rtc_base/platform_thread_types.cc @@ +44,5 @@ > #else > // Default implementation for nacl and solaris. > + // WEBRTC_BSD: pthread_t is a pointer, so cannot be casted to pid_t > + // (aka int32_t) on 64-bit archs. Required on OpenBSD. > + return reinterpret_cast<long>(pthread_self()); Does this apply for nacl and solaris as well, or does it need to be behind another #elif defined(WEBRTC_BSD)?
|
||
Comment 28•2 years ago
•
|
||
Nico, you covered my concerns in the review.
Landry, you should now be able to see the comments/questions at the bottom of the splinter review as well as here in line.
|
|
Assignee | |
Comment 29•2 years ago
|
||
(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #27)
Comment on attachment 9255254 [details] [diff] [review]
1654448-webrtc_bsd.diffReview of attachment 9255254 [details] [diff] [review]:
::: dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh
@@ +65,5 @@hg purge
else
echo "There are modified files in the checkout. Cowardly aborting!"
echo "$MODIFIED_FILES"
+# exit 1This should stay. I understand that it may be a bit annoying when you are
having to repeatedly change things.
100% agree, as i said in my previous comment. That's not meant for commit.
@@ +93,5 @@
CONFIGS="$CONFIGS x64_True_x86_win x64_False_x86_win"
IS_WIN=1
+elif [ "x$SYS_NAME" = "xOpenBSD" ]; then
- CONFIGS="x64_False_x64_openbsd x64_True_x64_openbsd"
+# CONFIGS="$CONFIGS x64_False_arm64_openbsd x64_True_arm64_openbsd"If the intent is to defer doing the work for arm (which is fine) could you
add a comment?
I dont have access to arm64 hw (and found nobody interested in fixing it), but looking at the moz.build generated bits it doesnt seem there's much differences (eg i didnt see many arch-specific bits) so maybe with the OpenBSD machine-independent changes arm64 would build. I'd be fine dropping that commented line.
::: third_party/libwebrtc/build/config/BUILDCONFIG.gn
@@ +306,5 @@when all files that depend on the assignment have been converted to import
the file directly. See https://crbug.com/1018739#c69.
+#import("//build/config/deprecated_default_sources_assignment_filter.gni")
+#sources_assignment_filter = deprecated_default_sources_assignment_filterNote to MJF: this doesn't appear to exist upstream any more. I am ok with
taking this as long the other platforms continue to generate correctly.
I'm fine leaving those lines too, not wanting to disturb other platforms. I just had to comment them because the gn binary i had from chromium build choked on them.
::: third_party/libwebrtc/rtc_base/platform_thread_types.cc
@@ +44,5 @@#else
// Default implementation for nacl and solaris.
- // WEBRTC_BSD: pthread_t is a pointer, so cannot be casted to pid_t
- // (aka int32_t) on 64-bit archs. Required on OpenBSD.
- return reinterpret_cast<long>(pthread_self());
Does this apply for nacl and solaris as well, or does it need to be behind
another #elif defined(WEBRTC_BSD)?
that bit was backported straight from https://hg.mozilla.org/integration/mozilla-inbound/rev/7317f657a9a7#l8.41 - i tried with uintptr_t but its type definition wasnt available in the context so i resorted to long. see also bug #1326011 for the background (those bits were fixed ... many times)
how should we proceed from that point ? as i said im probably not going through the pain of phabricator where i never manage to understand the process to update a review, and i tried many times and lost too many hours.
What i can do is upload fixed diffs / hg commits to this bug a la mercurial queues (something that always worked) for review, and one of you pushes those to phabricator/try ?
- one commit adding the two json files
- one commit adding the two mozconfig file
- one commit with the 'support OpenBSD' modifications
- one commit with all the generated moz.build bits, generated on OpenBSD ? i saw that it changed some include paths for non-OpenBSD so i'd like to be sure it doesnt break tier-1.
does this 'process' sound right to you ? timing wise, i'd like to get this commited to m-c soon (eg next week) so that we have time to get it backported to beta, if possible. And i suppose some ppl are on PTO too :)
|
|
Reporter | |
Comment 30•2 years ago
|
||
Landry, that sounds like it will work. After you upload, we'll regenerate the json and build files for the Tier 1+2 platforms, and push the whole thing to try. When they are ready to land, we'll take your patches from here a phabricator and from there we will land them. Thanks for need-infoing both of us, as you said it is the holidays, but we would like to help you get this landed.
|
|
Assignee | |
Comment 31•2 years ago
|
||
|
|
Assignee | |
Comment 32•2 years ago
|
||
|
|
Assignee | |
Comment 33•2 years ago
|
||
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 34•2 years ago
|
||
|
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 35•2 years ago
|
||
Comment on attachment 9256139 [details] [diff] [review] mozconfig files for OpenBSD/amd64 Review of attachment 9256139 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/media/webrtc/third_party_build/gn-configs/x64_True_x64_openbsd.mozconfig @@ +1,1 @@ > +mk_add_options PYTHON=/usr/local/bin/python3.9 How safe is pinning this to a specific version of python3? If there is a specific reason for this version could you add comment here?
|
|
Assignee | |
Comment 36•2 years ago
|
||
(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #35)
Comment on attachment 9256139 [details] [diff] [review]
mozconfig files for OpenBSD/amd64Review of attachment 9256139 [details] [diff] [review]:
:::
dom/media/webrtc/third_party_build/gn-configs/x64_True_x64_openbsd.mozconfig
@@ +1,1 @@+mk_add_options PYTHON=/usr/local/bin/python3.9
How safe is pinning this to a specific version of python3? If there is a
specific reason for this version could you add comment here?
oh that .. well that's the default py3 version in OpenBSD since the beginning of november. I wasnt sure we shipped a python3 symlink in the default python package, but i rechecked and it seems we do so that could be /usr/local/bin/python3 - anyway i'm probably going to be the only one running the generator bits on OpenBSD, so i'll know how to deal with it :)
|
|
||
Comment 37•2 years ago
|
||
I'm building an OpenBSD VM here to verify that we can reproduce the same results. My default python is Python 3.8.12 in an OpenBSD 7.0 image pulled from: https://cdn.openbsd.org/pub/OpenBSD/7.0/amd64/install70.iso in the last day or two.
Is there a newer version of OpenBSD I should be using?
|
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 38•2 years ago
|
||
|
|
Reporter | |
Comment 39•2 years ago
|
||
those intermediate files were generated with generate-gn-build-files.sh
Depends on D134431
|
|
Reporter | |
Comment 40•2 years ago
|
||
only OpenBSD/amd64 is supported for now
Depends on D134432
|
|
||
Comment 41•2 years ago
|
||
|
|
Reporter | |
Comment 42•2 years ago
•
|
||
Comment on attachment 9256424 [details]
Bug 1654448 - P3 - moz.build updates to support OpenBSD/amd64 builds. r?ng!
Beta/Release Uplift Approval Request
- User impact if declined: Firefox will not be buildable on OpenBSD.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): The risk to T1 & T2 platforms is minimal. These patches should not effect the build of those platforms. This patchset does however touch a very large number of moz.build files. Those changes are limited to OpenBSD, but it is still a xlarge patch by lines of code and potential difficulty to back out later. Although we have not landed this in nightly yet, we plan to before uplifting. Beta 8 is being cut today, which only leaves beta9. Is there still time to uplift this, or will it need to ride the next train?
- String changes made/needed: none
|
|
Reporter | |
Updated•2 years ago
|
|
|
||
Comment 43•2 years ago
|
||
|
|
||
Comment 44•2 years ago
|
||
Try run showing pre-existing Wayland failures:
https://treeherder.mozilla.org/jobs?repo=try&revision=e813f38f6e2ec1ca51ad9efedeaa0eb6a6fc54d4
|
|
||
Comment 45•2 years ago
|
||
Try run showing pre-existing Beetmover failures:
https://treeherder.mozilla.org/jobs?repo=try&revision=f38c6c5899e4d5f58b19558f85d93f1816e91551
|
||
Comment 46•2 years ago
|
||
Pushed by mfroman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f6cb3f02f642 P0 - add mozconfig files for OpenBSD/amd64;r=mjf https://hg.mozilla.org/integration/autoland/rev/559dc402b912 P1 - add generated json files for OpenBSD/amd64;r=mjf https://hg.mozilla.org/integration/autoland/rev/0300b32b7de7 P2 - readd partial support for BSD to webrtc build;r=mjf https://hg.mozilla.org/integration/autoland/rev/79fa1cfba14e P3 - moz.build updates to support OpenBSD/amd64 builds. r=ng
|
|
Assignee | |
Comment 47•2 years ago
|
||
(In reply to Michael Froman [:mjf] from comment #37)
I'm building an OpenBSD VM here to verify that we can reproduce the same results. My default python is Python 3.8.12 in an OpenBSD 7.0 image pulled from: https://cdn.openbsd.org/pub/OpenBSD/7.0/amd64/install70.iso in the last day or two.
Is there a newer version of OpenBSD I should be using?
nah dont worry, we now default to 3.9 in -current (so it'll be default in the upcoming 7.1 in may) but 7.0 is indeed the last released version, shipping python 3.8 as the default python3.
many thanks for:
- trying to build an OpenBSD VM :)
- doing the try run
- doing the phabricator madness
- requesting approval for beta - that's awesome if its backported, otherwise i'll have it locally backported in our port for 96 and remove patches in 97
i'll make sure to pull m-c once this is merged from autoland and recheck everything is fine.
|
||
Comment 48•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/f6cb3f02f642
https://hg.mozilla.org/mozilla-central/rev/559dc402b912
https://hg.mozilla.org/mozilla-central/rev/0300b32b7de7
https://hg.mozilla.org/mozilla-central/rev/79fa1cfba14e
|
|
Assignee | |
Comment 49•2 years ago
|
||
fwiw i've pulled m-c, cleaned up/stripped my patches/commits, completely dropped my objdir and my build fails with the same symptoms as previously...
68:22.63 third_party/libwebrtc/api/audio_codecs/L16/audio_decoder_L16_gn
68:25.01 third_party/libwebrtc/api/audio_codecs/L16/audio_encoder_L16_gn
68:25.04 In file included from Unified_cpp_aec3_factory_gn0.cpp:2:
68:25.04 In file included from /home/landry/src/m-c/third_party/libwebrtc/api/audio/echo_canceller3_factory.cc:14:
68:25.04 In file included from /home/landry/src/m-c/third_party/libwebrtc/modules/audio_processing/aec3/echo_canceller3.h:30:
68:25.04 In file included from /home/landry/src/m-c/third_party/libwebrtc/rtc_base/race_checker.h:15:
68:25.04 /home/landry/src/m-c/third_party/libwebrtc/rtc_base/platform_thread_types.h:47:1: error: unknown type name 'PlatformThreadId'
68:25.04 PlatformThreadId CurrentThreadId();
68:25.04 ^
68:25.05 /home/landry/src/m-c/third_party/libwebrtc/rtc_base/platform_thread_types.h:52:1: error: unknown type name 'PlatformThreadRef'
68:25.05 PlatformThreadRef CurrentThreadRef();
68:25.05 ^
68:25.06 /home/landry/src/m-c/third_party/libwebrtc/rtc_base/platform_thread_types.h:55:29: error: unknown type name 'PlatformThreadRef'
68:25.06 bool IsThreadRefEqual(const PlatformThreadRef& a, const PlatformThreadRef& b);
68:25.06 ^
68:25.07 /home/landry/src/m-c/third_party/libwebrtc/rtc_base/platform_thread_types.h:55:57: error: unknown type name 'PlatformThreadRef'
68:25.07 bool IsThreadRefEqual(const PlatformThreadRef& a, const PlatformThreadRef& b);
68:25.07 ^
68:25.08 In file included from Unified_cpp_aec3_factory_gn0.cpp:2:
68:25.08 In file included from /home/landry/src/m-c/third_party/libwebrtc/api/audio/echo_canceller3_factory.cc:14:
68:25.08 In file included from /home/landry/src/m-c/third_party/libwebrtc/modules/audio_processing/aec3/echo_canceller3.h:30:
68:25.08 /home/landry/src/m-c/third_party/libwebrtc/rtc_base/race_checker.h:37:20: error: unknown type name 'PlatformThreadRef'
68:25.08 mutable volatile PlatformThreadRef accessing_thread_;
as if WEBRTC_POSIX was still not defined.. but it is present in the OpenBSD blocks from https://hg.mozilla.org/mozilla-central/rev/79fa1cfba14e - i've tried diffing that commit with my locally generated changes and they seem to be the same, so .. i'm puzzled.
the backend.mk files in the objdir/third_party/libwebrtc/ subdirs have zero defines for WEBRTC_POSIX or WEBRTC_BSD. i dunno though if there should be some.. any idea ?
|
|
Assignee | |
Comment 50•2 years ago
|
||
i've probably messed up my local checkout when stripping, disregard previous comment .. sigh. mercurial is hard.
|
|
Assignee | |
Comment 51•2 years ago
|
||
better after properly updating my checkout to tip, all backend.mk files have the right DEFINES:
$grep -rl DEFINES.*WEBRTC_POSI /usr/obj/m-c/third_party/libwebrtc/|wc -l
344
build still churning, will confirm that runtime is also fine.
|
|
Assignee | |
Comment 52•2 years ago
|
||
well, something else fails to build but that feels unrelated to webrtc, rather cubeb..
5:48.53 error[E0432]: unresolved imports `backend::MidiInputPort`, `backend::MidiInput`, `backend::MidiInputConnection`, `backend::MidiOutputPort`, `backend::MidiOutput`, `backend::MidiOutputConnection`
5:48.53 --> /home/landry/src/m-c/third_party/rust/midir/src/common.rs:5:5
5:48.53 |
5:48.53 5 | MidiInputPort as MidiInputPortImpl,
5:48.53 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiInputPort` in `backend`
5:48.53 6 | MidiInput as MidiInputImpl,
5:48.53 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiInput` in `backend`
5:48.53 7 | MidiInputConnection as MidiInputConnectionImpl,
5:48.53 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiInputConnection` in `backend`
5:48.54 8 | MidiOutputPort as MidiOutputPortImpl,
5:48.54 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiOutputPort` in `backend`
5:48.54 9 | MidiOutput as MidiOutputImpl,
5:48.54 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiOutput` in `backend`
5:48.54 10 | MidiOutputConnection as MidiOutputConnectionImpl
5:48.54 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiOutputConnection` in `backend`
5:48.73 For more information about this error, try `rustc --explain E0432`.
5:50.94 error: could not compile `midir` due to previous error
that's bug #1747196 which piled on top
|
|
||
Comment 53•2 years ago
|
||
Comment on attachment 9256414 [details]
Bug 1654448 - P0 - add mozconfig files for OpenBSD/amd64;r?mjf
Approved for 96.0b9
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Comment 54•2 years ago
|
||
| bugherder uplift | ||
|
|
||
Comment 55•2 years ago
|
||
Backed out of 96 beta for causing build failures, see below:
Backout link #1
Backout link #2
The error occurred while processing the following file: /builds/worker/checkouts/gecko/third_party/libwebrtc/moz.build
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 56•2 years ago
|
||
mike, any idea for that perma-failure on 96 ? https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=bdbc6bcf3d8c182256548e1c10b4963365e34cec
seems you seem to be involved in fixing many of those ...
|
||
Comment 57•2 years ago
|
||
The error occurred while processing the following file:
/builds/worker/checkouts/gecko/third_party/libwebrtc/moz.build
The underlying problem is we referenced a path that does not exist. That path is:
/builds/worker/checkouts/gecko/third_party/libwebrtc/modules/video_coding/codecs/av1/libaom_av1_decoder_gn/moz.build
IOW, you need different patches on beta because of bug 1744644.
|
|
Assignee | |
Comment 58•2 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #57)
The error occurred while processing the following file:
/builds/worker/checkouts/gecko/third_party/libwebrtc/moz.build
The underlying problem is we referenced a path that does not exist. That path is:
/builds/worker/checkouts/gecko/third_party/libwebrtc/modules/video_coding/codecs/av1/libaom_av1_decoder_gn/moz.buildIOW, you need different patches on beta because of bug 1744644.
strange, because those patches applied fine on beta 8 afaict.. i dunno how you managed to gather that information from the bazillion of logfiles in that job... thanks ! maybe its possible to just resubmit the patch without that chunk ?
dianna, i guess this is too late for 96 anyway now ?
|
|
Assignee | |
Comment 59•2 years ago
|
||
mjf, since you landed https://hg.mozilla.org/integration/autoland/rev/38c455e19287, any idea ? given the timeline, maybe i'll just give up on 96...
|
|
||
Comment 61•2 years ago
•
|
||
Agreed - there are 4 other patches required to include 38c455e19287. They're definitely not complicated, but it is late in the cycle to justify uplifting. This can ride the trains.
|
||
Comment 62•2 years ago
|
||
phabricator is user hostile for ppl not using daily. i've tried it, and gave up trying to be productive with it.
we wrote a simple tutorial for you ;)
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
|
|
Assignee | |
Comment 63•2 years ago
|
||
(In reply to Sylvestre Ledru [:Sylvestre] from comment #62)
phabricator is user hostile for ppl not using daily. i've tried it, and gave up trying to be productive with it.
we wrote a simple tutorial for you ;)
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
thanks, that looks much better than the last things i read a while ago! moz-phab (and mercurial) itself is still a sluggish monstrosity :) but i guess i'll have to blame it on my slow vm disk..
|
|
||
Comment 64•2 years ago
|
||
you can use git for contributions too (almost 30% of the contributions are done using git)
|
|
Assignee | |
Comment 65•2 years ago
|
||
(In reply to Sylvestre Ledru [:Sylvestre] from comment #64)
you can use git for contributions too (almost 30% of the contributions are done using git)
i know, i know, i've just been meaning to do that for ages but my time left for contributions is scarce, so changing workflows and ditching worktrees is always more work :)
|
||
Updated•2 years ago
|
Description
•