See http://buildbot.rhaalovely.net/nine/#/builders/3/builds/41/steps/7/logs/stdio for last log, started failing on build 24 which matches when #1393119 was pushed. base/event.h:19:2: error: "Must define either WEBRTC_WIN or WEBRTC_POSIX." is probably the main offender.

Jan, iirc you worked a bit on gn, does m-i build for you on freebsd ?

The more i look at the gn files, the more i want to cry. It seems all the work that has been done in bug #807492 has to be redone from scratch, as it seems absolutely zero care has been taken for non-linux-win-macos operating systems. From what i understand, the moz.build files are now generated by gn. And there are billions of gn files, without clues about which ones are coming from upstream (ie not modifiable without going upstream, which would be an herculean task) or which ones are mozilla-specific that we could patch.. only media/webrtc/webrtc.mozbuild ? others ? And what about all the sndio bits from bug #911450 and bug #1351378 ? I'll try hacking my way around, but this doesnt look very promising.

All of the BUILD.gn files come from upstream. I've made changes to support our build on "tier-1" platforms (Android, Linux, Win, OS X). The bright side is that I was able to get a good portion of my changes landed upstream, so they are willing to accept build system patches. The down side is that it was months of work to get those platforms working and I had the advantage that those platforms were already supported upstream. Here is the build system documentation on using gn [1]. I'm not certain how much work would be involved in getting gn running on bsd. Another possibility would be to copy and modify one of the intermediate json files for Linux [2] and see if you can get that to work for bsd by changing preprocessor defines and source files appropriately. The downside of that approach is that you would be stuck doing that again each time we do an update from upstream. [1] https://firefox-source-docs.mozilla.org/build/buildsystem/gn.html [2] https://searchfox.org/mozilla-central/source/media/webrtc/gn-configs/x64_True_x64_linux.json

The other sad option is giving up on WebRTC on *BSD by using --disable-webrtc, until --disable-webrtc is unsupported, at which point we might give up on firefox on *BSD and get on with our lives :) So, which files are we allowed to modify within m-c that wouldnt be overwritten by merges from upstream ? [2] is a joke, there's no way anyone in their sane mind would manually poke at a 350kb/9000+ lines generated vomit.

Firefox 60 build is currently broken on FreeBSD as well. Confusingly, GnConfigGen didn't work *until* bug 1393119 landed. $ pkg install python27 chromium-gn $ ./mach bootstrap $ ./mach configure $ ./mach build-backend -b GnConfigGen 0:00.10 obj-x86_64-unknown-freebsd11.1/_virtualenv/bin/python obj-x86_64-unknown-freebsd11.1/config.status --backend GnConfigGen Reticulating splines... Running "/usr/local/bin/gn gen obj-x86_64-unknown-freebsd11.1/gn-output --args=is_debug=false host_cpu="x64" target_os="freebsd" target_cpu="x64" --ide=json" ERROR at //build/config/BUILDCONFIG.gn:222:5: Assertion failed. assert(false, "Unsupported host_os: $host_os") ^----- Unsupported host_os: bsd Traceback (most recent call last): File "obj-x86_64-unknown-freebsd11.1/config.status", line 1302, in <module> config_status(**args) File "python/mozbuild/mozbuild/config_status.py", line 150, in config_status the_backend.consume(definitions) File "python/mozbuild/mozbuild/backend/base.py", line 128, in consume if (not self.consume_object(obj) and File "python/mozbuild/mozbuild/gn_processor.py", line 545, in consume_object obj.gn_input_variables, obj.gn_sandbox_variables) File "python/mozbuild/mozbuild/gn_processor.py", line 516, in generate_gn_config subprocess.check_call(gen_args, cwd=srcdir, stderr=subprocess.STDOUT) File "/usr/local/lib/python2.7/subprocess.py", line 186, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/usr/local/bin/gn', 'gen', 'obj-x86_64-unknown-freebsd11.1/gn-output', u'--args=is_debug=false host_cpu="x64" target_os="freebsd" target_cpu="x64"', '--ide=json']' returned non-zero exit status 1 $ gn --version UNKNOWN $ pkg info -x gn chromium-gn-61.0.3163.100_5 After that I just couldn't find time to re-do bug 807492 et al. with no hope for upstreaming: - Google is as privacy-hostile as always, requiring to join the panopticon just to sign CLA - WebRTC is married to Chromium which in turn has bitrotten FreeBSD/OpenBSD support (no DragonFly or NetBSD) - I don't have a microphone or camera to check for regressions; my interest is in Data Channels for games and p2p WebRTC use of gn reminds me of https://www.youtube.com/watch?v=NSemlYagjIU after the following media/webrtc/trunk/build/config/BUILDCONFIG.gn: # Do not add more is_* variants here for random lesser-used Unix systems like # aix or one of the BSDs. If you need to check these, just check the # current_os value directly.

For what it's worth, I am not happy at all about breaking things for you. The alternative for us would be to maintain a bunch of hand written moz.build files which would slow down every update we do from upstream webrtc.org. We're typically a year or so behind upstream as it is and the further behind we fall, the worse the updates become. We will continue to maintain a set of local patches against the gn build files. Not everything we changed is something they would be willing to accept upstream. I would also be willing to try to get your build system patches landed upstream. I don't know if you would still have to sign a CLA for that to happen. I can understand not wanting to spend the time to get gn working on the bsds. It would be a large amount of not very enjoyable work. I don't see why we would stop supporting --disable-webrtc builds. From what I've seen in the past, bugs reporting that --disable-webrtc is broken are fixed quickly. I realize that none of these are great options. I'm sorry.

Well gn itself "works" because we have ports of chromium, and i can run "make configure" in chromium port to have a "working" gn binary on openbsd, but i find this highly ironic. And our chromium copy of gn is patched to make it believe openbsd is a linux variant, which is hackish. Hacking around BUILDCONFIG.gn, i can generate media/webrtc/gn-configs/x86_False_x86_openbsd.json & media/webrtc/gn-configs/x64_False_x64_openbsd.json files, and will see how it builds, but as jan said, we have to redo all the work of adapting all the build madness for the specificities of the BSDs. Not even speaking about the sndio bits...

I'm making some (insanely painful) progress, but right now im stuck on how to make BUILD.gn files accept my changes (ie add atomic32_non_darwin_unix.cc to sources in https://dxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/system_wrappers/BUILD.gn#108 when the os is bsd) So far i understood from the doc that after whacking BUILDCONFIG.gn i need to run the mach GnConfigGen voodoo to generate the os-specific gn-config files, then run $./mach build-backend -b GnMozbuildWriter to add the corresponding os-specific defines to moz.build files, but im not sure if i should also run GnMozbuildWriter after *every* BUILD.gn os-specific modification. I'm starting to regret autotools and plain makefiles.

I have a shell script that I run after every gn file change: #!/bin/bash ./mach build-backend -b GnConfigGen cp obj-x86_64-pc-linux-gnu/gn-output/x64_True_x64_linux.json media/webrtc/gn-configs/ ./mach build-backend -b GnMozbuildWriter You also need to run ./mach configure when you switch configurations (i.e. enable/disable debug). Otherwise you'll continue to generate json files for the previous configuration. Sigh.

How.. convenient. Well, at least i know i was doing things in the wrong order, so from now on i'll separate my work in distinct patches: - BUILDCONFIG.gn changes for bsd - generated gn-configs for openbsd from GnConfigGen - generated moz.build changes from GnMozbuildWriter - BUILD.gn changes for bsd - generated moz.build changes from GNMozbuildWriter (from the previous changes) this way we'll better see what changes what.

It would make sense to keep the BUILDCONFIG.gn changes separate as I don't think we'll be able to upstream those. I'm hoping we can upstream the BUILD.gn stuff for bsd. By the way, with the changes in Bug 1397793, we should no longer need the sndio stuff in WebRTC, it should all be handled by the cubeb library. That bug switched to using a fake audio device rather than using the webrtc.org platform specific audio devices. I'm not building the platform specific audio devices as part of the next upstream webrtc.org merge and it is working ok on Linux, which is the only platform I have building at the moment. I'll have to see how it goes as I try other platforms. I've had problems in the past on Android, where even though we weren't using the audio device, we were still initializing it and that was having an effect on the rest of the audio code.

(In reply to Dan Minor [:dminor] from comment #11) > It would make sense to keep the BUILDCONFIG.gn changes separate as I don't > think we'll be able to upstream those. I'm hoping we can upstream the > BUILD.gn stuff for bsd. > > By the way, with the changes in Bug 1397793, we should no longer need the > sndio stuff in WebRTC, it should all be handled by the cubeb library. That > bug switched to using a fake audio device rather than using the webrtc.org > platform specific audio devices. Good, one less thing to worry about. So far i'm only fighting with BUILD.gn files to get the atomic32 bits and the videocapture bits built on bsd, but it seems running the mozbuild generator only doesnt generate changes from the BUILD.gn files in moz.build output.

$./mach build-backend -b GnMozbuildWriter ... Finished reading 1375 moz.build files in 30.10s Read 63 gyp files in parallel contributing 0.00s to total wall time Processed into 9831 build config descriptors in 11.35s GnMozbuildWriter backend executed in 3.20s 1 total backend files; 0 created; 0 updated; 1 unchanged; 0 deleted Total wall time: 45.82s; CPU time: 22.88s; Efficiency: 50%; Untracked: 1.18s Well, it takes into account my gn-config files for openbsd (since i already have some generated changes from BUILDCONFIG.gn in the moz.build files) but it doesnt modify more the moz.build files when i do changes that should at least impact the sources....

I think i finally understood in which order steps should be done (ie even if you change only BUILD.gn, you need to run the two backends and get the gn-config file from objdir, ugh, this is really awful), so will now refine the bits needed to fix all webrtc parts on openbsd.

So i finally have a rough patchset that allows me to build with webrtc on openbsd. Totally untested at runtime of course. One of the issues left is that i didn't manage to get the video_capture source from linux to be enabled/built on BSD via gn - ie adding is_bsd (which is added to BUILDCONFIG.gn and used here and there in my patchset) to https://dxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/video_capture/BUILD.gn#99 didnt add the missing sources list to the generated json file for openbsd, so i had to copy the bits from the linux json file (https://dxr.mozilla.org/mozilla-central/source/media/webrtc/gn-configs/x64_False_x64_linux.json#6941) to have the moz.build files correctly adapted by the GnMozbuildWriter. Dunno how acceptable that is. I didnt have similar issues to other places where i added is_bsd, so i dunno what's so special about the video_capture os specific bits. Any hint ?

After some runtime testing (and force-toggling the full duplex thing for audio, per bug 1444074) it seems: - audio recording via sndio/cubeb works - the webcam seems detected (uvideo) and works on https://mozilla.github.io/webrtc-landing/gum_test_aec.html and talky.io - i can try/allow the screen/window sharing but it displays nothing - i guess i need to fiddle a bit more with the is_x11/is_linux bits in the buildconfig. At least the basic features of webrtc are somewhat detected, even if not everything actually 'works' (but im not sure that's a regression from before gn). Are there better official tests than https://mozilla.github.io/webrtc-landing/ https://www.webrtc-experiment.com/ ? For someone wanting to reproduce this on another BSD, inspired from dminor's script: - build/get a gn binary (here, i just run 'make configure in chromium port) - export GN=/path/to/gn - mach configure (so that config.status has the path to GN) - modify/hack BUILDCONFIG.gn and various BUILD.gn files - mach build-backend -b GnConfigGen - cp $OBJDIR/media/webrtc/trunk/gn-output/*.json media/webrtc/gn-configs/ - manually tweak the json file - mach build-backend -b GnMozbuildWriter - if needed manually adapt some moz.build files which arent updated for some reasons - mach build

This one tweaks things here and there to build linux bits on bsd - for some reason (as i said in a previous comment) the video_capture change isnt taken into account when regenerating the json config, so the latter had to be hand-edited. Meh.

In this one, the media/webrtc/trunk/webrtc/modules/video_capture/video_capture_internal_impl_gn/moz.build chunk which modifies UNIFIED_SOURCES comes from the hand-editing of the json file, ie adding: "sources": [ "//webrtc/modules/video_capture/linux/device_info_linux.cc", "//webrtc/modules/video_capture/linux/device_info_linux.h", "//webrtc/modules/video_capture/linux/video_capture_linux.cc", "//webrtc/modules/video_capture/linux/video_capture_linux.h" ], in the "//webrtc/modules/video_capture:video_capture_internal_impl" section. Randall, Dan, i'd like your feedback on this way of doing things, and which bits can be upstreamed (as jan, i'm not going to do it, i have no desire to sign up to the crazyness of the google platform for everything). Should we try to group the BSD changes in a single patchset for Free/Open/Net ? Should i also generate the debug json configs ? Maybe i'll try i386, even if it's soon going to die because native rust on 32-bits is more and more a dead end...

With a few minor tweaks it now builds on FreeBSD as well. I haven't tested DragonFly yet as my VM was ancient, so recreating...

Comment on attachment 8957838 [details] [diff] [review] BUILDCONFIG.gn changes for openbsd Review of attachment 8957838 [details] [diff] [review]: ----------------------------------------------------------------- ::: media/webrtc/trunk/build/config/BUILDCONFIG.gn @@ +135,5 @@ > # separate flags. > is_official_build = false > > # Whether we're a traditional desktop unix. > + is_desktop_linux = current_os == "linux" || current_os == "openbsd" Not used by WebRTC, see https://cs.chromium.org/search/?q=is_desktop_linux @@ +193,5 @@ > # block should have propagated a value down. > # TODO(dpranke): Add some sort of assert here that verifies that > # no toolchain omitted host_toolchain from its toolchain_args(). > > + if (host_os == "linux" || host_os == "openbsd") { Only useful if you plan to support cross-compilation from OpenBSD to Linux. Looking at Chromium port[1] it doesn't appear so. So, the magic can be stubbed out. [1] https://github.com/openbsd/ports/blob/cd95ba0f06bf/www/chromium/patches/patch-build_toolchain_openbsd_BUILD_gn @@ +232,5 @@ > _default_toolchain = "//build/toolchain/android:android_clang_$target_cpu" > } else { > _default_toolchain = "//build/toolchain/android:android_$target_cpu" > } > +} else if (target_os == "chromeos" || target_os == "linux" || target_os == "openbsd") { Same as above. @@ +383,5 @@ > + is_mac = false > + is_nacl = false > + is_posix = true > + is_win = false > + is_bsd = true Other platforms may need to explicitly define `is_bsd = false`

(In reply to Landry Breuil (:gaston) from comment #21) > In this one, the > media/webrtc/trunk/webrtc/modules/video_capture/ > video_capture_internal_impl_gn/moz.build chunk which modifies > UNIFIED_SOURCES comes from the hand-editing of the json file, ie adding: > > "sources": [ > "//webrtc/modules/video_capture/linux/device_info_linux.cc", > "//webrtc/modules/video_capture/linux/device_info_linux.h", > > "//webrtc/modules/video_capture/linux/video_capture_linux.cc", > "//webrtc/modules/video_capture/linux/video_capture_linux.h" > ], > > in the "//webrtc/modules/video_capture:video_capture_internal_impl" section. In gyp we've adjusted exclude rules to allow using _linux files e.g., https://dxr.mozilla.org/mozilla-central/rev/bbac8c59d58c/media/webrtc/trunk/webrtc/build/filename_rules.gypi#29-39 https://dxr.mozilla.org/mozilla-central/rev/bbac8c59d58c/media/webrtc/trunk/build/filename_rules.gypi#27-37

And it didn't take long to find exclude rules. https://searchfox.org/mozilla-central/source/media/webrtc/trunk/build/config/BUILDCONFIG.gn#457-465

(In reply to Landry Breuil (:gaston) from comment #16) > - i can try/allow the screen/window sharing but it displays nothing Ditto on FreeBSD even with Firefox 59 which still uses gyp.

Comment on attachment 8957841 [details] [diff] [review] BUILD.gn changes Awesome! After comparing gyp vs. gn only WEBRTC_THREAD_RR appears to be missing.

Comment on attachment 8957839 [details] gn config for OpenBSD/amd64 (non-debug) There's a way to cheat testing on all BSDs. ;) --- x64_False_x64_openbsd.json +++ x64_False_x64_freebsd.json @@ -3,13 +3,13 @@ "host_cpu": "x64", "is_debug": false, "target_cpu": "x64", - "target_os": "openbsd" + "target_os": "freebsd" }, "mozbuild_args": { "CPU_ARCH": "x86_64", "HOST_CPU_ARCH": "x86_64", "MOZ_DEBUG": null, - "OS_TARGET": "OpenBSD" + "OS_TARGET": "FreeBSD" }, "sandbox_vars": { "COMPILE_FLAGS": {

Comment on attachment 8957957 [details] [diff] [review] BUILDCONFIG.gn changes for all BSDs Nevermind, I'll upload the whole patchset instead.

Changes from Landry's patchset: - DragonFly, FreeBSD, NetBSD configs - i386 for all (tested on FreeBSD i386) - aarch64 for FreeBSD (FF59 was green[1]) - include _linux.cc to fix build - WEBRTC_THREAD_RR (like in gyp) What's left: - bisecting screen capture regression - testing on DragonFly (low priority) - adressing feedback [1] http://thunderx1.nyi.freebsd.org/data/111arm64-quarterly/463850/logs/firefox-58.0.2,1.log

Oops, wrong link. I can't actually test FF60 on aarch64 due to lack of hardware. qemu-aarch64-static (from qemu-user) crashes when running "rustc" but there's no cross-compilation friendly Rust package downstream. However, for GnConfigGen it was enough to cheat Rust dependency by hardcoding values in build/moz.configure/rust.configure. [1] http://thunderx1.nyi.freebsd.org/data/111arm64-default/463867/logs/firefox-59.0,1.log

(In reply to Landry Breuil (:gaston) from comment #16) > https://www.webrtc-experiment.com/ Screen sharing demo there stopped working after mozilla-central changeset 6ab062f29097. Not the first time their demos have Firefox compatibility issues.

Comment on attachment 8957989 [details] Bug 1437670 - Add basic BSD support to GN build. f=gaston https://reviewboard.mozilla.org/r/226920/#review232798 This looks good to me. Please separate the changes under trunk/build from the changes under trunk/webrtc into separate commits. I have only been attempting to upstream things under trunk/webrtc and plan to maintain trunk/build locally. From what I can tell, the trunk/build stuff is shared across chromium and I think we would have a much more difficult time upstreaming it. Having the commits separated will make it easier for me to upstream. r+ once the commits are separated.

Comment on attachment 8957988 [details] Bug 1437670 - Regenerate mozbuild for WebRTC. f=gaston https://reviewboard.mozilla.org/r/226918/#review232800 lgtm

Comment on attachment 8957990 [details] Bug 1437670 - Add WebRTC's gn-configs for BSDs. f=gaston https://reviewboard.mozilla.org/r/226922/#review232802

Comment on attachment 8957990 [details] Bug 1437670 - Add WebRTC's gn-configs for BSDs. f=gaston https://reviewboard.mozilla.org/r/226922/#review232804 lgtm

(In reply to Jan Beich from comment #25) > Created attachment 8957957 [details] [diff] [review] > BUILDCONFIG.gn changes for all BSDs > > And it didn't take long to find exclude rules. > > https://searchfox.org/mozilla-central/source/media/webrtc/trunk/build/config/ > BUILDCONFIG.gn#457-465 Ah, good catch :) Testing your patchset here. > Screen sharing demo there stopped working after mozilla-central changeset > 6ab062f29097. Not the first time their demos have Firefox compatibility > issues. Is there another reference website to test such a feature then ?

(In reply to Landry Breuil (:gaston) from comment #44) > Is there another reference website to test such a feature then ? - https://mozilla.github.io/webrtc-landing/gum_test.html then click Window - https://appear.in/ then open a chat then click on Share Screen at the bottom

Comment on attachment 8957989 [details] Bug 1437670 - Add basic BSD support to GN build. f=gaston https://reviewboard.mozilla.org/r/226920/#review232798 trunk/build changes are now in a separate commit. I've slightly improved commit messages as well.

(In reply to Jan Beich from comment #49) > (In reply to Landry Breuil (:gaston) from comment #44) > > Is there another reference website to test such a feature then ? > > - https://mozilla.github.io/webrtc-landing/gum_test.html then click Window doesnt work here, only shows a blank area when i select one of the listed windows - same thing for whole screen sharing. > - https://appear.in/ then open a chat then click on Share Screen at the > bottom same thing on appear.in no webcam or mic here but your patchset builds fine here - will do more runtime testing with mic/cam tonight.

(In reply to Landry Breuil (:gaston) from comment #51) > (In reply to Jan Beich from comment #49) > > (In reply to Landry Breuil (:gaston) from comment #44) > > > Is there another reference website to test such a feature then ? > > > > - https://mozilla.github.io/webrtc-landing/gum_test.html then click Window > > doesnt work here, only shows a blank area when i select one of the listed > windows - same thing for whole screen sharing. Do you seen preview when selecting a window but before clicking on Allow button? If not maybe check enabled X11 extensions: Composite, DAMAGE, XFIXES. Otherwise, try bisecting Firefox 52-60 range or insert debug printfs to https://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/desktop_capture/window_capturer_x11.cc screen/window/application capture demo works fine on FreeBSD 12/Xserver 1.19.6 using the patches here but my configuration maybe unusual.

Testing with webcam & mic still works with your patchset, so that's a yay ! (In reply to Jan Beich from comment #52) > Do you seen preview when selecting a window but before clicking on Allow > button? If not maybe check enabled X11 extensions: Composite, DAMAGE, > XFIXES. There's no preview (well preview shows a blank square in the permission doorhanger) - xdpyinfo showsComposite, DAMAGE and XFIXES. I dunno if its' the same composite as i need to disable compositing in my WM for now (issues with ati driver being worked on) Anyway, not really a regression as i dont remember this ever working here, and low-hanging fruit.

I can't test DragonFly as rustup isn't supported[1] while downstream rust package is too old[2]. Otherwise, GnConfigGen output matches existing patch here: both regular and debug. [1] https://static.rust-lang.org/dist/channel-rust-stable.toml [2] http://muscles.dragonflybsd.org/synth/logs/lang___rust.log https://github.com/DragonFlyBSD/DeltaPorts/commits/master/ports/lang/rust (In reply to Landry Breuil (:gaston) from comment #53) > There's no preview (well preview shows a blank square in the permission > doorhanger) - xdpyinfo showsComposite, DAMAGE and XFIXES. Looking at XServerPixelBuffer::CaptureRect it can use MIT-SHM or XImage. Try either raising SysV IPC limits (e.g., kern.shminfo.shmall=131072 chasing FreeBSD[3]) or disable MIT-SHM in xorg.conf (see manpage for an example). [3] https://svnweb.freebsd.org/changeset/base/209037

Comment on attachment 8957989 [details] Bug 1437670 - Add basic BSD support to GN build. f=gaston https://reviewboard.mozilla.org/r/226920/#review233418 lgtm

Comment on attachment 8958143 [details] Bug 1437670 - Restore BSD support in WebRTC. f=jbeich https://reviewboard.mozilla.org/r/227082/#review233420 lgtm

The changes look fine to me, please feel free to land them once you're satisfied with your testing.

Landry, do we still wait for Randell's (module owner) feedback? Anything else? Otherwise, obsolete non-MozReview patches then mark checkin-needed.

Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/autoland/rev/10c8936ce55b Add basic BSD support to GN build. r=dminor f=gaston https://hg.mozilla.org/integration/autoland/rev/1c0c0526d0e8 Restore BSD support in WebRTC. r=dminor f=jbeich https://hg.mozilla.org/integration/autoland/rev/656b5e04ed5f Add WebRTC's gn-configs for BSDs. r=dminor f=gaston https://hg.mozilla.org/integration/autoland/rev/e76f046da74b Regenerate mozbuild for WebRTC. r=dminor f=gaston

Comment on attachment 8957988 [details] Bug 1437670 - Regenerate mozbuild for WebRTC. f=gaston https://treeherder.mozilla.org/#/jobs?repo=try&revision=7d08ab37441fdaa66b49502343086b17c739e732 Approval Request Comment [Feature/Bug causing the regression]: bug 1393119 [User impact if declined]: Broken build on DragonFly, FreeBSD, NetBSD, OpenBSD unless .mozconfig contains --disable-webrtc [Is this code covered by automated tests?]: Yes, mochitest-mda{,-e10s}. [Has the fix been verified in Nightly?]: Yes, both Firefox 61 and 60. [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: Can only break build. [String changes made/needed]: None

Comment on attachment 8957989 [details] Bug 1437670 - Add basic BSD support to GN build. f=gaston See comment 60.

Comment on attachment 8957990 [details] Bug 1437670 - Add WebRTC's gn-configs for BSDs. f=gaston See comment 60.

Comment on attachment 8958143 [details] Bug 1437670 - Restore BSD support in WebRTC. f=jbeich See comment 60.

Fwiw i've also backported all those patches on top of 60.0b3 and runtime-tested the webcam/mic there.

https://hg.mozilla.org/mozilla-central/rev/10c8936ce55b https://hg.mozilla.org/mozilla-central/rev/1c0c0526d0e8 https://hg.mozilla.org/mozilla-central/rev/656b5e04ed5f https://hg.mozilla.org/mozilla-central/rev/e76f046da74b

Comment on attachment 8957988 [details] Bug 1437670 - Regenerate mozbuild for WebRTC. f=gaston fix webrtc bsd build, beta60+

https://hg.mozilla.org/releases/mozilla-beta/rev/5d519dfb2238 https://hg.mozilla.org/releases/mozilla-beta/rev/8a093b3af5b5 https://hg.mozilla.org/releases/mozilla-beta/rev/61411e330c4f https://hg.mozilla.org/releases/mozilla-beta/rev/14c6d0ff23ab