flypig.co.uk

Yesterday I fixed a barrage of errors that appeared in the storage directory, all seemingly related to incorrect use of the mozilla and mozilla::storage namespaces. In particular, where the code contained qualified namespaces, such as mozilla::storage::method(), the compiler was interpreting this as mozilla::storage::mozilla::storage::method(). The namespace was being added again.

I fixed all of these manually; it took an age. At the end of it I was left with the nagging question: why is this causing a problem for my build, when it doesn't cause a problem for Mozilla's build? Could it be that these files aren't being used by upstream at all?

On inspecting the history of the files with git blame the answer became clear. It turns out to be more prosaic than that.

In an earlier change I added a new header to the top of the mozStorageService.cpp file. This was the change, made by me, which introduced it:

$ git log -1 38be5c5c7302f
commit 38be5c5c7302f34ad013e0e68cd69f9aac5725eb
Author: David Llewellyn-Jones 
Date:   Thu Aug 10 00:21:01 2023 +0100

    [PATCH] Revert "Bug 1611386 - Drop support for --enable-system-sqlite. r=asuth,glandium"
    
    This reverts commit b5b6473a6d6d59e1361e529db9b8b6e1f7448f29.

This was fine, except that it turns out the header was reverted back into the wrong place (or maybe things were changed around it later that caused this issue). Anyway, in short, changing the ordering of the lines from this:

namespace mozilla {
namespace storage {

#include "nsIPromptService.h"

To this:

#include "nsIPromptService.h"

namespace mozilla {
namespace storage {

Actually resolved all of these namespace issues. It's frustrating that I did all that work yesterday and the solution turned out to be much simpler, but more realistically I think I wouldn't have figured this out without having gone through all of that pain and learning it the hard way anyway.

Progress is progress!

The next error is of a completely different variety. This is encouraging: it feels like we're reaching a stage where the library might build.

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

It's worth noticing that this error is coming from the third_party/libwebrtc folder. We have several patches for WebRTC which you can see in the rpm folder and put together by Denis Grigorev. Denis is a very talented developer and did a huge amount of work on this for ESR 78; one of the tasks involved regenerating the build files related to WebRTC. Mozilla provide some details about this, but right now this looks like a rather intrusive set of changes (translation: a lot of effort).

Given the amount of work involved, I've decided to disable the WebRTC functionality for now rather than try to reapply these patches. This isn't to say the changes aren't important: I consider the WebRTC features to be a really useful and important addition to the browser. It was one of the really nice advances we had moving from ESR 60 to ESR 78. But this is a big task requiring the reintroduction of at least four large patches, so right now it makes sense to push it back until after everything else is building.

To that end, rather than attempting to apply all the related patches I've decided to do this instead:

diff --git a/embedding/embedlite/config/mozconfig.merqtxulrunner b/embedding/embedlite/config/mozconfig.merqtxulrunner
index 2593d32fd5a9..bec8b01bb07b 100644
--- a/embedding/embedlite/config/mozconfig.merqtxulrunner
+++ b/embedding/embedlite/config/mozconfig.merqtxulrunner
@@ -48,3 +48,3 @@ ac_add_options --with-app-name=xulrunner-qt5
 # disabling for now, since the build fails...
-ac_add_options --enable-webrtc
+ac_add_options --disable-webrtc
 ac_add_options --enable-profiling

A much simpler change; one which I hope we'll be able to reverse later.

Because this is a configuration change that goes right to the heart of the build system, I'm going to have to do a full rebuild. So this may be the last change I get to make for today.

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

Let's see in the morning how that's gone.

As always, if you want to read my other posts they're available in my full Gecko Dev Diary.