1437670 - webrtc fails to build on bsd since switch to gn build

Status: RESOLVED FIXED

Description

[Landry Breuil (:gaston)]

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.

Comment 1

[Landry Breuil (:gaston)]

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

Comment 2

[Landry Breuil (:gaston)]

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.

Comment 3

[Dan Minor [:dminor]]

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

Comment 4

[Landry Breuil (:gaston)]

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.

Comment 5

[Jan Beich]

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.

Comment 6

[Dan Minor [:dminor]]

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.

Comment 7

[Landry Breuil (:gaston)]

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...

Comment 8

[Landry Breuil (:gaston)]

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.

Comment 9

[Dan Minor [:dminor]]

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.

Comment 10

[Landry Breuil (:gaston)]

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.

Comment 11

[Dan Minor [:dminor]]

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.

Comment 12

[Landry Breuil (:gaston)]

(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.

Comment 13

[Landry Breuil (:gaston)]

$./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....

Comment 14

[Landry Breuil (:gaston)]

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.

Comment 15

[Landry Breuil (:gaston)]

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 ?

Comment 16

[Landry Breuil (:gaston)]

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

Comment 17

[Landry Breuil (:gaston)]

Created attachment 8957838 [details] [diff] [review]
BUILDCONFIG.gn changes for openbsd

Comment 18

[Landry Breuil (:gaston)]

Created attachment 8957839 [details]
gn config for OpenBSD/amd64 (non-debug)

Comment 19

[Landry Breuil (:gaston)]

Created attachment 8957840 [details] [diff] [review]
moz.build changes from OpenBSD/amd64 gn-config

Comment 20

[Landry Breuil (:gaston)]

Created attachment 8957841 [details] [diff] [review]
BUILD.gn changes

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.

Comment 21

[Landry Breuil (:gaston)]

Created attachment 8957842 [details] [diff] [review]
moz.build changes from the BUILD.gn fixes

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...

Comment 22

[Jan Beich]

Created attachment 8957951 [details] [diff] [review]
bug-1437670-buildconfig.diff

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 23

[Jan Beich]

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`

Comment 24

[Jan Beich]

(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

Comment 25

[Jan Beich]

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

Comment 26

[Jan Beich]

(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 27

[Jan Beich]

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 28

[Jan Beich]

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 29

[Jan Beich]

Comment on attachment 8957957 [details] [diff] [review]
BUILDCONFIG.gn changes for all BSDs

Nevermind, I'll upload the whole patchset instead.

Comment 30

[Jan Beich]

Created attachment 8957988 [details]
Bug 1437670 - Regenerate mozbuild for WebRTC.  f=gaston

Review commit: https://reviewboard.mozilla.org/r/226918/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/226918/

Comment 31

[Jan Beich]

Created attachment 8957989 [details]
Bug 1437670 - Add basic BSD support to GN build.  f=gaston

Review commit: https://reviewboard.mozilla.org/r/226920/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/226920/

Comment 32

[Jan Beich]

Created attachment 8957990 [details]
Bug 1437670 - Add WebRTC's gn-configs for BSDs.  f=gaston

Based on output from FreeBSD i386/amd64/aarch64 and OpenBSD amd64.

Review commit: https://reviewboard.mozilla.org/r/226922/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/226922/

Comment 33

[Jan Beich]

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

Comment 34

[Jan Beich]

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

Comment 35

[Jan Beich]

(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 36

[Dan Minor [:dminor]]

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 37

[Dan Minor [:dminor]]

Comment on attachment 8957988 [details]
Bug 1437670 - Regenerate mozbuild for WebRTC.  f=gaston

https://reviewboard.mozilla.org/r/226918/#review232800

lgtm

Comment 38

[Dan Minor [:dminor]]

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

https://reviewboard.mozilla.org/r/226922/#review232802

Comment 39

[Dan Minor [:dminor]]

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

https://reviewboard.mozilla.org/r/226922/#review232804

lgtm

Comment 40

[Jan Beich]

Created attachment 8958143 [details]
Bug 1437670 - Restore BSD support in WebRTC.  f=jbeich

Original porting was done in bug 807492, so this is mostly gyp->gn translation.
The changes don't touch cflags/libs as those aren't used by Gecko.

Review commit: https://reviewboard.mozilla.org/r/227082/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/227082/

Comment 41

[Jan Beich]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/226920/diff/1-2/

Comment 42

[Jan Beich]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/226922/diff/1-2/

Comment 43

[Jan Beich]

Comment on attachment 8957988 [details]
Bug 1437670 - Regenerate mozbuild for WebRTC.  f=gaston

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/226918/diff/1-2/

Comment 44

[Landry Breuil (:gaston)]

(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 ?

Comment 45

[Jan Beich]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/226920/diff/2-3/

Comment 46

[Jan Beich]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/227082/diff/1-2/

Comment 47

[Jan Beich]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/226922/diff/2-3/

Comment 48

[Jan Beich]

Comment on attachment 8957988 [details]
Bug 1437670 - Regenerate mozbuild for WebRTC.  f=gaston

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/226918/diff/2-3/

Comment 49

[Jan Beich]

(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 50

[Jan Beich]

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.

Comment 51

[Landry Breuil (:gaston)]

(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.

Comment 52

[Jan Beich]

(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.

Comment 53

[Landry Breuil (:gaston)]

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.

Comment 54

[Jan Beich]

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 55

[Dan Minor [:dminor]]

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 56

[Dan Minor [:dminor]]

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

https://reviewboard.mozilla.org/r/227082/#review233420

lgtm

Comment 57

[Dan Minor [:dminor]]

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

Comment 58

[Jan Beich]

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

Comment 59

[Pulsebot]

Pushed by [e-mail]:
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 60

[Jan Beich]

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 61

[Jan Beich]

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

See comment 60.

Comment 62

[Jan Beich]

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

See comment 60.

Comment 63

[Jan Beich]

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

See comment 60.

Comment 64

[Landry Breuil (:gaston)]

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

Comment 65

[Tiberius Oros[:tiberius_oros]]

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 66

[Julien Cristau [:jcristau]]

Comment on attachment 8957988 [details]
Bug 1437670 - Regenerate mozbuild for WebRTC.  f=gaston

fix webrtc bsd build, beta60+

Comment 67

[Dorel Luca [:dluca]]

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