flypig.co.uk

So far I've been trying to apply WebRTC patches. There are five of them, 77 – 81, of which 77 and 78 have already been applied. Well, sort of. The first applied fine but for the second I copied over the GN build configuration json files and regenerated the build scripts hoping that would do the trick.

I left the build running overnight and, unlike my previous attempts, it now compiles without error. That's a positive step forwards. But although compilation goes through, the linking now fails.

There are a lot of missing symbols. Here are some of the errors; I won't give them all as they're repetitive to say the least. But this gives a decently representative sample of them.

285:37.36 toolkit/library/build/libxul.so
289:04.49 SailfishOS-devel-aarch64.default/opt/cross/bin/
    aarch64-meego-linux-gnu-ld: ../../../dom/media/systemservices/
    Unified_cpp_systemservices0.o: in function `webrtc::ScreenDeviceInfoImpl::
    GetDeviceName(unsigned int, char*, unsigned int, char*, unsigned int, 
    char*, unsigned int, int*)':
289:04.49 ${PROJECT}/gecko-dev/dom/media/systemservices/video_engine/
    desktop_capture_impl.cc:63: undefined reference to `webrtc::
    DesktopDisplayDevice::DesktopDisplayDevice()'
289:04.49 SailfishOS-devel-aarch64.default/opt/cross/bin/
    aarch64-meego-linux-gnu-ld: ${PROJECT}/gecko-dev/dom/media/systemservices/
    video_engine/desktop_capture_impl.cc:63: undefined reference to `webrtc::
    DesktopDisplayDevice::~DesktopDisplayDevice()'
289:04.49 SailfishOS-devel-aarch64.default/opt/cross/bin/
    aarch64-meego-linux-gnu-ld: ${PROJECT}/gecko-dev/dom/media/systemservices/
    video_engine/desktop_capture_impl.cc:81: undefined reference to `webrtc::
    DesktopDisplayDevice::getDeviceName()'
[...]
289:04.51 SailfishOS-devel-aarch64.default/opt/cross/bin/
    aarch64-meego-linux-gnu-ld: libxul.so: hidden symbol 
    `_ZN6webrtc15DesktopCapturer20CreateScreenCapturerERKNS_21DesktopCaptureOptionsE' isn't defined
289:04.51 SailfishOS-devel-aarch64.default/opt/cross/bin/
    aarch64-meego-linux-gnu-ld: final link failed: bad value
289:04.51 collect2: error: ld returned 1 exit status

All bar one of the issues are undefined reference errors. There's also one hidden symbol error which I'll come on to. But first, the missing symbols, all of which are inside the webrtc namespace, are the following:

1. ScreenDeviceInfoImpl::GetDeviceName()
2. DesktopDisplayDevice::DesktopDisplayDevice()
3. DesktopDisplayDevice::~DesktopDisplayDevice()
4. DesktopDisplayDevice::getDeviceName()
5. DesktopDisplayDevice::getUniqueIdName()
6. WindowDeviceInfoImpl::GetDeviceName()
7. DesktopDisplayDevice::getPid()
8. BrowserDeviceInfoImpl::GetDeviceName()
9. DesktopTab::DesktopTab()
10. DesktopTab::~DesktopTab()
11. DesktopTab::getTabName()
12. DesktopTab::getUniqueIdName()
13. DesktopDeviceInfoImpl::Create()
14. DesktopCaptureOptions::CreateDefault()
15. DesktopCaptureOptions::~DesktopCaptureOptions()
16. DesktopCapturer::CreateScreenCapturer()
17. MouseCursorMonitor::CreateForScreen()
18. DesktopAndCursorComposer::DesktopAndCursorComposer()
19. DesktopCapturer::CreateWindowCapturer()
20. MouseCursorMonitor::CreateForWindow(webrtc::DesktopCaptureOptions()
21. DesktopCapturer::CreateTabCapturer()
22. DesktopRegion::DesktopRegion()
23. DesktopRegion::~DesktopRegion()
24. EncoderSimulcastProxy::EncoderSimulcastProxy()

The single hidden symbol is for the following:

_ZN6webrtc15DesktopCapturer20CreateScreenCapturerERKNS_21
    DesktopCaptureOptionsE

Running this through the demangler gives the following name:

$ c++filt _ZN6webrtc15DesktopCapturer20CreateScreenCapturerERKNS_21
    DesktopCaptureOptionsE
webrtc::DesktopCapturer::CreateScreenCapturer(
    webrtc::DesktopCaptureOptions const&
)

As we can see this is also one of the missing symbols. A missing symbol usually means one of two things. It can mean that the header file is being compiled without a related source file, so that there's a call to a method that the compiler can provide a symbol for, but then the linker can't hook it up to the actual function. Alternatively it can mean that there's some object code being generated that's not being included in the final linking step.

I'm not sure what's going on here, but I do note that there are implementations for most of these methods in the code. For example DesktopDisplayDevice::getDeviceName() can be found in the desktop_device_info.cc file:

const char *DesktopDisplayDevice::getDeviceName() {
  return deviceNameUTF8_;
}

Amongst the patches I don't see any obvious change that would immediately try to link in a missing object file. There are some changes to the build configuration that would affect what's compiled, for example the following:

     UNIFIED_SOURCES += [
-        "/third_party/libwebrtc/webrtc/modules/video_capture/linux/
    device_info_linux.cc",
-        "/third_party/libwebrtc/webrtc/modules/video_capture/linux/
    video_capture_linux.cc"
+        "/third_party/libwebrtc/webrtc/modules/video_capture/sfos/
    device_info_sfos.cc",
+        "/third_party/libwebrtc/webrtc/modules/video_capture/sfos/
    video_capture_sfos.cc"
     ]

There also seem to be some relevant relationships between the missing symbols and some of the later patches too. For example patch 81 contains the a new method called DeviceInfoSFOS::GetDeviceName(). Now that's not going to generate an exact replacement for the ScreenDeviceInfoImpl::GetDeviceName() symbol, but it's surely related.

From the descriptions in the patches it's also clear that patches 77, 78 and 79 are all supposed to be applied together, since they were all worked on under bug JB#53756 (The "JB" here stands for "Jolla Bug" and the number is the bug number in Jolla's Bugzilla database).

My conclusion is that I should probably try applying patch 79 and attempt to build again before I start attempting any manual fixes myself. It's possible the linking errors will just go away if I do this.

Patch 79 makes changes to just a single file and that file doesn't appear to have moved, so maybe it'll just apply?

$ git am --3way ../rpm/
    0079-sailfishos-webrtc-Disable-desktop-sharing-feature-on.patch
Applying: Disable desktop sharing feature on SFOS. JB#53756
Using index info to reconstruct a base tree...
M       dom/media/systemservices/VideoEngine.cpp
Falling back to patching base and 3-way merge...
Auto-merging dom/media/systemservices/VideoEngine.cpp

The patch failed initially, but after adding the -3way option to fall back to a three-way merge it then applies fine. The patch is quite small and I was able to easily check manually that all of the elements had correctly applied.

So I've set the build going again. It's another fully clean build, so I'm expecting it to take some time. Looking at the output the last build took four and three quarter hours before it reached the linking stage. Right now it's 16:45, so with any luck it'll be completed (either with or without errors) by 21:30 which might still give me some time to do some more work on it afterwards.

[...]

The build ran pretty much to schedule. Unfortunately it didn't go through, failing once again at the final linking stage. But the results are encouraging nevertheless. While last time there were 24 undefined references, now there's only one:

274:07.07 toolkit/library/build/libxul.so
277:37.26 SailfishOS-devel-aarch64.default/opt/cross/bin/
    aarch64-meego-linux-gnu-ld: ../../../dom/media/webrtc/libwebrtcglue/
    Unified_cpp_libwebrtcglue0.o: in function `mozilla::WebrtcVideoConduit::
    CreateEncoder(webrtc::VideoCodecType)':
277:37.26 ${PROJECT}/gecko-dev/dom/media/webrtc/libwebrtcglue/VideoConduit.cpp:
    1774: undefined reference to `webrtc::EncoderSimulcastProxy::
    EncoderSimulcastProxy(webrtc::VideoEncoderFactory*, webrtc::SdpVideoFormat 
    const&)'
277:37.26 collect2: error: ld returned 1 exit status

Extracting the crucial information from this error, the undefined reference is for the following method:

webrtc::EncoderSimulcastProxy::EncoderSimulcastProxy()

A quick check shows that this class doesn't exist in ESR 78, although there was what appears to be a similar VP8EncoderSimulcastProxy class that's used instead. I also notice that the WebrtcVideoConduit::CreateEncoder() method where the constructor for the class is used (which is causing the linker error) is heavily amended by our patch 80.

This is going to require further investigation, but it does at least give us a clear set of leads to follow. But as it's late now, following these leads will have to wait until tomorrow. I'm feeling quite upbeat about this though: it's very clear progress.

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