flypig.co.uk

Today I'm continuing my attempts to restore WebRTC to the browser. Last night I set off a completely clean build after re-enabling the WebRTC option in mozconfig.merqtxulrunner. I didn't expect the build to complete successfully and, indeed, it didn't. After four and a half hours it crashed out with an error while attempting a header include:

272:51.05 In file included from ${PROJECT}/gecko-dev/third_party/libwebrtc/
    webrtc/modules/desktop_capture/desktop_capturer.cc:17,
272:51.05                  from Unified_cpp_p_capture_generic_gn0.cpp:56:
272:51.05 ${PROJECT}/obj-build-mer-qt-xr/dist/system_wrappers/gtk/gtk.h:3:15: 
    fatal error: gtk/gtk.h: No such file or directory
272:51.05  #include_next <gtk/gtk.h>
272:51.06                ^~~~~~~~~~~
272:51.06 compilation terminated.
272:51.06 make[4]: *** [${PROJECT}/gecko-dev/config/rules.mk:694: 
    Unified_cpp_p_capture_generic_gn0.o] Error 1

Our build is Qt-, rather than GTK- based, so it's not surprising that there's a problem if it tries to include a GTK header. If we look at the source code we can see that the likely cause is that our change to the build options has resulted in the WEBRTC_USE_PIPEWIRE define macro being set.

#if defined(WEBRTC_USE_PIPEWIRE) || defined(USE_X11)
#include <gtk/gtk.h>
#include <gtk/gtkx.h>
#endif

Interestingly this code is the same in ESR 78, even after all of the patches have been applied. That suggests to me that, in fact, WEBRTC_USE_PIPEWIRE shouldn't be defined on our build even if WebRTC is enabled. That would make sense because it can't be the case that all builds of Gecko require the GTK headers.

Checking the GN build file we can see the following:

  if (rtc_use_pipewire) {
    sources += [
      "linux/base_capturer_pipewire.cc",
      "linux/base_capturer_pipewire.h",
      "linux/screen_capturer_pipewire.cc",
      "linux/screen_capturer_pipewire.h",
      "linux/window_capturer_pipewire.cc",
      "linux/window_capturer_pipewire.h",
    ]

    if (!build_with_mozilla) {
      configs += [
        ":gio",
        ":pipewire",
      ]
    } else {
      defines += [ "WEBRTC_USE_PIPEWIRE" ]
      include_dirs += [ "/third_party/pipewire" ]
    }
  }

This shows that the define is dependent on both the rtc_use_pipewire option being set and the build_with_mozilla option being set. Searching for rtc_use_pipewire and comparing against ESR 78 shows that this wasn't set in ESR 78:

$ diff \
    gecko-dev-project/gecko-dev/gecko-dev/media/webrtc/trunk/webrtc/webrtc.gni \
    gecko-dev-esr91/gecko-dev/gecko-dev/third_party/libwebrtc/webrtc/webrtc.gni 
74c74
<   rtc_use_pipewire = false
---
>   rtc_use_pipewire = true

This appears to be a change to the upstream default. So the thing to do here is to unset this option and then, I suppose, regenerate all of the build scripts.

$ source `pwd`/obj-build-mer-qt-xr/rpm-shared.env
$ cd gecko-dev/
$ ./mach python python/mozbuild/mozbuild/gn_processor.py dom/media/webrtc/
    third_party_build/gn-configs/arm64_False_arm64_linux.json
$ ./mach python python/mozbuild/mozbuild/gn_processor.py dom/media/webrtc/
    third_party_build/gn-configs/arm_False_arm_linux.json
$ ./mach python python/mozbuild/mozbuild/gn_processor.py dom/media/webrtc/
    third_party_build/gn-configs/x86_False_x86_linux.json

However, running these gives the same result as before: no change at all. That doesn't seem right to me, but it's always possible that the change will be propagated at build time automatically somehow. So I've set another clean build running again:

git clean -xdf
cd gecko-dev
git clean -xdf
cd ..
sfdk build -d -p --with git_workaround
[...]

As I mentioned earlier, yesterday the build ran for four and a half hours before hitting the error, so we should expect it to run for at least the same length of time again. So I'm off to focus on other things for a bit and will return once the build has completed, error or otherwise.

[...]

Unfortunately it's given the same error as before. What's frustrating is that I can quite clearly see the following in moz.build:

if CONFIG["CPU_ARCH"] == "aarch64" and 
    CONFIG["OS_TARGET"] == "Linux":

    DEFINES["DISABLE_NACL"] = True
    DEFINES["NO_TCMALLOC"] = True
    DEFINES["WEBRTC_USE_PIPEWIRE"] = True

    LOCAL_INCLUDES += [
        "/third_party/pipewire/"
    ]

    UNIFIED_SOURCES += [
        "/third_party/libwebrtc/webrtc/modules/desktop_capture/linux/
    base_capturer_pipewire.cc",
        "/third_party/libwebrtc/webrtc/modules/desktop_capture/linux/
    screen_capturer_pipewire.cc",
        "/third_party/libwebrtc/webrtc/modules/desktop_capture/linux/
    window_capturer_pipewire.cc"
    ]

So I probably should have just checked this before starting an entirely fresh build off again: it could have saved me some time. Anyhow, I'm a bit stumped. How to regenerate these GN json build files?

After trying a few things and not making much progress, I've decide to take a closer look at patch 78. That's the patch with the changes to the build configuration. The various moz.build files there look autogenerated, but the three json files — the GN input scripts — don't. Could it be that Denis edited these by hand?

It seems unlikely given they each have 6000 lines of changed code. But I don't see where else they would have come from. The WebRTC code has been moved in the build tree but otherwise seems pretty similar. So now I'm wondering if I can get away with simply copying these GN build files over from ESR 78 straight into ESR 91.

This is a bit of a risky way to proceed, but I don't have a lot to lose at this point. Besides, the way my repository is set up right now, it'd be super-easy to revert the changes. So I'm going to give it a go.

$ cp gecko-dev-project/gecko-dev/gecko-dev/media/webrtc/gn-configs/
    arm64_False_arm64_linux.json gecko-dev-esr91/gecko-dev/gecko-dev/dom/media/
    webrtc/third_party_build/gn-configs/
$ cp gecko-dev-project/gecko-dev/gecko-dev/media/webrtc/gn-configs/
    arm_False_arm_linux.json gecko-dev-esr91/gecko-dev/gecko-dev/dom/media/
    webrtc/third_party_build/gn-configs/
$ cp gecko-dev-project/gecko-dev/gecko-dev/media/webrtc/gn-configs/
    x86_False_x86_linux.json gecko-dev-esr91/gecko-dev/gecko-dev/dom/media/
    webrtc/third_party_build/gn-configs/

By looking through various bugs on Bugzilla (specifically Bug 1466254 and Bug 1658853) I've also discovered I can regenerate all of the build files from the GN json files in one go using just one command. This needs to be executed inside the scratchbox2 target of course:

$ ./mach build-backend -b GnMozbuildWriter

After running this I can see a large number of changed files, primarily moz.build files, all related to the build configuration. Maybe this has done the job? Given all of these changes I'm willing to run a build to see how it goes. Given there are changes to the build scripts it's going to have to be another completely clean build though.

git clean -xdf
cd gecko-dev
git clean -xdf
cd ..
sfdk build -d -p --with git_workaround
[...]

Once again, it'll likely take a while for this to either fail or go through. So that'll probably be my lot for the day.

[...]

It's now bed time. The build has been running for a bit over three and a half hours and continues onwards. So I'll definitely have to leave this until morning. Let's see how things look then.

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.