flypig.co.uk

The majority of development yesterday was taken up with reapplying patch 0002 to "Bring back the Qt layer". I also adjusted a couple of build flags. Triggering a rebuild we immediately hit a similar issue today.

 0:18.59 checking whether cross compiling... no
 0:20.19 Traceback (most recent call last):
 0:20.19   File "${PROJECT}/configure.py", line 226, in 
 0:20.19     sys.exit(main(sys.argv))
 0:20.20   File "${PROJECT}/configure.py", line 50, in main
 0:20.20     sandbox.run(os.path.join(os.path.dirname(__file__), "moz.configure"))
 0:20.20   File "${PROJECT}/python/mozbuild/mozbuild/configure/__init__.py", line 554, in run
 0:20.20     raise InvalidOptionError(msg)
 0:20.20 mozbuild.configure.options.InvalidOptionError: Unknown option: --enable-dconf

Here "dconf" is a reference to Gnome's low-level configuration system. This is a key-value pair database (similar to the Windows registry) that also happens to be heavily used for configuration settings on Sailfish OS. Part of the reason for its appeal on Sailfish OS is that there are really nice QML bindings for it, but there's actually been a move away from it in recent releases.

For gecko enable-dconf is a Sailfish-specific flag that enables dconf access, which is used by patch 0061 to get the 12/24 hour time format setting from dconf. Without the patch there is no flag, so when we try to set it in the build configuration (having assumed that the patch is applied when it's not) the build complains and fails.

We'll need to add this patch back later, but adding it before the build is working would again be premature. So I've simply taken the code that introduced the flag from the patch and added it back in to build/moz.configure/old.configure even though as yet it won't be doing anything.

That gets the build moving again. An alternative would have been to remove the use of the flag from embedding/embedlite/config/mozconfig.merqtxulrunner, but right now the result is the same and I think I'm more likely to remember if I do things this way around.

Slowly but surely the build is progressing. Now we have the following error:

 0:20.33 Traceback (most recent call last):
 0:20.33   File "${PROJECT}/configure.py", line 226, in 
 0:20.34     sys.exit(main(sys.argv))
 0:20.34   File "${PROJECT}/configure.py", line 50, in main
 0:20.34     sandbox.run(os.path.join(os.path.dirname(__file__), "moz.configure"))
 0:20.34   File "${PROJECT}/python/mozbuild/mozbuild/configure/__init__.py", line 554, in run
 0:20.34     raise InvalidOptionError(msg)
 0:20.34 mozbuild.configure.options.InvalidOptionError: Unknown option: --enable-system-sqlite

Yet another missing option, again something that would ordinarily be added by a patch we're not yet applying. This is for patch 0088 with the title "Drop support for --enable-system-sqlite". The patch looks relatively straightforward, so I thought it might be worth checking whether it just applies as-is. Here's what I get when I give this a go:

$ patch -d gecko-dev -p1 < rpm/0088-Revert-Bug-1611386-Drop-support-for-enable-system-sq.patch 
patching file browser/installer/package-manifest.in
Hunk #1 succeeded at 142 (offset 1 line).
patching file build/moz.configure/old.configure
Hunk #1 FAILED at 228.
1 out of 1 hunk FAILED -- saving rejects to file build/moz.configure/old.configure.rej
patching file config/external/sqlite/moz.build
Hunk #1 FAILED at 4.
1 out of 1 hunk FAILED -- saving rejects to file config/external/sqlite/moz.build.rej
patching file old-configure.in
Hunk #1 succeeded at 57 with fuzz 1 (offset -2 lines).
Hunk #2 succeeded at 2128 (offset 88 lines).
patching file storage/SQLiteMutex.h
patching file storage/moz.build
Hunk #1 succeeded at 99 with fuzz 2 (offset 1 line).
patching file storage/mozStorageConnection.cpp
Hunk #1 succeeded at 877 (offset 113 lines).
patching file storage/mozStorageService.cpp
Hunk #1 succeeded at 35 with fuzz 2 (offset 4 lines).
Hunk #2 succeeded at 166 (offset -17 lines).
patching file third_party/sqlite3/src/moz.build
Hunk #1 succeeded at 79 (offset -1 lines).
Hunk #2 succeeded at 89 with fuzz 1 (offset -1 lines).
patching file third_party/sqlite3/src/sqlite.symbols

The results aren't quite as bad as I'd feared they might be: only two failed hunks. The reason these hunks are failing is that Mozilla have switched from using single quotes to double quotes as their default Python string delimiter throughout the Python build scripts. That's going to cause havoc for pretty-much all the patches that touch the build process.

Nevertheless, armed with this knowledge, adding the two failing hunks is straightforward. I apply the patch, commit the changes, and try again.

The enable-system-sqlite flag now goes through. What's next? The configure flag steps now all go through, which means the configure script is getting a lot further. But it does still fail, seemingly because of lack of availability for a specific version of NSPR.

NSPR stands for Netscape Portable Runtime and is one of the gecko build dependencies. According to the packaging, it:
 
That's all pretty crucial stuff and as the error makes clear, the version installed in my SDK is too old:

 0:29.31 ERROR: Requested 'nspr >= 4.32' but version of NSPR is 4.29.0

Checking the version in the repositories I see the error is correct:

$ sfdk engine exec
[mersdk@f1c636fdd533 gecko-dev]$ sb2 -t SailfishOS-devel-aarch64.default
[SB2 sdk-build SailfishOS-devel-aarch64.default] gecko-dev $ zypper search --details nspr
Loading repository data...
Reading installed packages...

S  | Name             | Type       | Version                 | Arch    | Repository
---+------------------+------------+-------------------------+---------+-----------
i  | nspr             | package    | 4.29.0+git2-1.3.3.jolla | aarch64 | oss
   | nspr             | srcpackage | 4.29.0+git2-1.3.3.jolla | noarch  | oss
   | nspr-debuginfo   | package    | 4.29.0+git2-1.3.3.jolla | aarch64 | oss
   | nspr-debugsource | package    | 4.29.0+git2-1.3.3.jolla | aarch64 | oss
i+ | nspr-devel       | package    | 4.29.0+git2-1.3.3.jolla | aarch64 | oss

The spec file has a build requirement for NSPR, but it's set to be >= 4.25.0. It may be that we'll need to build an updated version of NSPR to get this to work. The requirement is coming from gecko-dev/build/moz.configure/nspr.configure. It's likely we won't be able to skip this requirement, but we can hack down the version requirement to see if we can still make progress in the meantime.

Changing the 4.32 to 4.29 in nspr.configure is nasty, but gets us past. We've still not reached the compilation step yet and the workaround will surely have to be addressed properly by the time we reach that point. But one step at a time. And the commit I've added makes clear what's going on, so I won't forget to fix this in the future.

Now we hit something more awkward:

 0:29.39 checking for rust host triplet...
 0:29.39 ERROR: The rust compiler host (i686-unknown-linux-gnu) is not suitable
         for the configure host (aarch64-unknown-linux-gnu).
 0:29.39 You can solve this by:
 0:29.39 * Set your configure host to match the rust compiler host by editing your
 0:29.39 mozconfig and adding "ac_add_options --host=i686-unknown-linux-gnu".
 0:29.39 * Or, install the rust toolchain for aarch64-unknown-linux-gnu, if
         supported, by running
 0:29.39 "rustup default stable-aarch64-unknown-linux-gnu"

Both scratchbox2 and rustc have cross-compilation capabilities. Getting them to work together for ESR78 was... let's just say it was challenging. We had to introduce some quite nasty workarounds. There's some nice advice from the error which will be worth trying, but it's quite late now, so something to try another day.

The fact it gets this far already is positive. Things are moving forwards.

If you're read through all the other entries in my diary up to now, I can only thank you and tell you I'm impressed with your perseverance. If not, feel free to check them out on my Gecko-dev Diary page.

There'll be more tomorrow.