flypig.co.uk

Yesterday we left things at the following error:

 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"

So now we have to tackle it. As I mentioned yesterday, this looks likely due to the peculiar cross-compilation-inside-a-cross-compilation environment that we're using for our build.

The good news is that we have a patch 0032 "Read rustc host from environment" which might help with this. Unfortunately it doesn't apply cleanly:

patching file build/moz.configure/rust.configure
Hunk #1 FAILED at 91.
Hunk #2 FAILED at 99.
2 out of 2 hunks FAILED -- saving rejects to file build/moz.configure/rust.configure.rej
patching file third_party/rust/cc/.cargo-checksum.json
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file third_party/rust/cc/.cargo-checksum.json.rej
patching file third_party/rust/cc/src/lib.rs
Hunk #1 FAILED at 1977.
Hunk #2 succeeded at 2639 (offset 381 lines).
Hunk #3 succeeded at 2683 (offset 381 lines).
1 out of 3 hunks FAILED -- saving rejects to file third_party/rust/cc/src/lib.rs.rej

However it's not a big patch, so maybe it can be fixed up manually? A quick glance at the changes suggests the problems are caused by the same quoting issue we saw yesterday, i.e. that all of the single quotes in the Python build code have been switched for double quotes.

That at least means that adding the remaining failed hunks turns out to be straightforward, and I was pretty astonished that this does in fact fix the issue. So we can swiftly move on to the next error:

 0:30.07 checking for cbindgen...
 0:30.07 DEBUG: trying cbindgen: /usr/bin/cbindgen
 0:30.07 DEBUG: Executing: `/usr/bin/cbindgen --version`
 0:30.07 DEBUG: /usr/bin/cbindgen has version 0.17.0
 0:30.07 DEBUG: trying cbindgen: /usr/bin/cbindgen
 0:30.07 DEBUG: Executing: `/usr/bin/cbindgen --version`
 0:30.07 DEBUG: /usr/bin/cbindgen has version 0.17.0
 0:30.07 DEBUG: trying cbindgen: /usr/bin/cbindgen
 0:30.07 DEBUG: Executing: `/usr/bin/cbindgen --version`
 0:30.08 DEBUG: /usr/bin/cbindgen has version 0.17.0
 0:30.08 ERROR: cbindgen version 0.17.0 is too old. At least version 0.19.0 is required.
 0:30.08 Please update using 'cargo install cbindgen --force' or running
 0:30.08 './mach bootstrap', after removing the existing executable located at
 0:30.08 /usr/bin/cbindgen.

I'm able to work around this by hacking the version check from 0.19.0 to 0.17.0 in build/moz.configure/bindgen.configure, but that just leads to the next similar error.

 0:30.34 checking for clang for bindgen... /usr/bin/clang++
 0:30.36 checking for libclang for bindgen... ${PROJECT}/../obj-build-mer-qt-xr/lib/libclang.so.10
 0:30.36 checking that libclang is new enough...
 0:30.37 ERROR: The libclang located at ${PROJECT}/../obj-build-mer-qt-xr/lib/libclang.so.10
         is too old (need at least 5.0).
 0:30.37 Please make sure to update it or point to a newer libclang using
 0:30.37 --with-libclang-path.

The libclang that it's checking against is ultimately coming from the clang-libs package in the Sailfish OS repositories. I'm able to hack around the check (once again to be found in bindgen.configure), but it's getting increasingly clear that performing the underlying package upgrades is going to be necessary, and that maybe I'd be better off biting the bullet and just doing the work to upgrade them.

It turns out there are more too:

 0:30.33 checking for icu-i18n >= 69.1... no
 0:30.33 ERROR: Requested 'icu-i18n >= 69.1' but version of icu-i18n is 68.2

Working around this involves hacking away at gecko-dev/js/moz.configure.

That's now NSPR, cbindgen, libclang and icu-i18n that all need upgrading.

Hacking around the last of these gets the build further...

 0:54.13 Reticulating splines...

...which is actually a bit of a milestone, since the crucial reticulating splines step signifies the shift from configuring the build process to actually starting the build.
 
With the build actually running, the next failure is something more interesting.

 0:54.13 Reticulating splines...
 0:59.17  0:05.38 File already read. Skipping: ${PROJECT}/intl/components/moz.build
 1:02.48  0:08.69 File already read. Skipping: ${PROJECT}/gfx/angle/targets/angle_common/moz.build
 1:20.38 Traceback (most recent call last):
 1:20.38   File "${PROJECT}/configure.py", line 226, in 
 1:20.39     sys.exit(main(sys.argv))
 1:20.39   File "${PROJECT}/configure.py", line 80, in main
 1:20.39     return config_status(config)
 1:20.39   File "${PROJECT}/configure.py", line 221, in config_status
 1:20.39     return config_status(args=[], **sanitized_config)
 1:20.39   File "${PROJECT}/python/mozbuild/mozbuild/config_status.py", line 174, in config_status
 1:20.39     definitions = list(definitions)
 1:20.39   File "${PROJECT}/python/mozbuild/mozbuild/frontend/emitter.py", line 167, in emit
 1:20.39     objs = list(emitfn(out))
 1:20.39   File "${PROJECT}/python/mozbuild/mozbuild/frontend/emitter.py", line 1397, in emit_from_context
 1:20.40     for obj in self._handle_linkables(context, passthru, generated_files):
 1:20.40   File "${PROJECT}/python/mozbuild/mozbuild/frontend/emitter.py", line 1041, in _handle_linkables
 1:20.40     raise SandboxValidationError(
 1:20.40 mozbuild.frontend.reader.SandboxValidationError:
 1:20.40 ==============================
 1:20.40 FATAL ERROR PROCESSING MOZBUILD FILE
 1:20.40 ==============================
 1:20.40 The error occurred while processing the following file or one of the files it includes:
 1:20.41     ${PROJECT}/widget/qt/moz.build
 1:20.41 The error occurred when validating the result of the execution. The reported error is:
 1:20.41     File listed in SOURCES does not exist: '${PROJECT}/widget/qt/nsNativeThemeQt.cpp'

From the error and file affected, it looks like this needs patch 0016 "Provide checkbox/radio renderer for Sailfish" to be applied to fix it. As well as providing a Sailfish OS checkbox/radio renderer, this patch also creates the widget/qt/nsNativeThemeQt.cpp file. My instinct tells me this is going to be a bit of work, it's late, and the sensible thing to do would be to wait until tomorrow to start this.

Except... I don't want to leave this alone. Let's continue.

So let's apply patch 0016 and create the widget/qt/nsNativeThemeQt.cpp file.

Surprisingly this time applying the patch works, albeit with a couple of the changes having already been applied:

$ patch -d gecko-dev -p1 < rpm/0016-sailfishos-qt-Provide-checkbox-radio-renderer-for-Sa.patch 
patching file layout/style/res/forms.css
Hunk #1 succeeded at 479 with fuzz 1 (offset -2 lines).
Hunk #2 succeeded at 489 with fuzz 1 (offset -1 lines).
patching file widget/qt/QtColors.h
patching file widget/qt/moz.build
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file widget/qt/moz.build.rej
patching file widget/qt/nsNativeThemeQt.cpp
patching file widget/qt/nsNativeThemeQt.h

Checking the git blame I can see that the duplicate changes were added when I applied the 0002 "Bring back Qt layer" patch. Why did that happen? It turns out it's because, rather than apply the patch for the new files added by patch 0002, instead I just copied the files over from the fully patched ESR78 build tree. It didn't occur to me that this would pull in changes that were applied to these files by later patches. D'oh! At least the reason is clear.

With the full patch 0016 applied, I kick off the build again. Now it actually, genuinely, appears to be building. I can tell because my legs are getting hot from my laptop fans!

It gets a little way in before generating an error I wasn't expecting. And one I'm as yet not at all sure how to tackle.

 2:42.29 config/system-header.sentinel.stub
 2:45.63 WARN: Skip mp4parse::MIN_SIZE - (not `pub`).
 2:45.63 WARN: Skip mp4parse::CONFIG_OBUS_OFFSET - (not `pub`).
 2:45.63 WARN: Skip mp4parse::MIN_PROPERTIES - (not `pub`).
 2:45.63 WARN: Skip mp4parse::MAX - (not `pub`).
 2:45.63 thread 'main' has overflowed its stack
 2:45.64 fatal runtime error: stack overflow
 2:45.64 qemu: uncaught target signal 6 (Aborted) - core dumped
 2:47.49 make[3]: *** [backend.mk:188: media/mp4parse-rust/.deps/mp4parse_ffi_generated.h.stub] Error 250
 2:47.49 make[3]: *** Waiting for unfinished jobs....
 3:45.71   in file included from `${PROJECT}/mobile/sailfishos/PEmbedLiteApp.ipdl', line 6:
 3:45.71 ${PROJECT}/mobile/sailfishos/PEmbedLiteView.ipdl:63: error: bad syntax near `compress'
 3:45.71 Specification could not be parsed.
 3:46.94 make[4]: *** [Makefile:30: ipdl.track] Error 1
 3:46.94 make[3]: *** [${PROJECT}/config/recurse.mk:99: ipc/ipdl/export] Error 2
 3:46.95 make[2]: *** [${PROJECT}/config/recurse.mk:34: export] Error 2
 3:46.95 make[1]: *** [${PROJECT}/config/rules.mk:355: default] Error 2
 3:46.95 make: *** [client.mk:65: build] Error 2
 3:46.95 0 compiler warnings present.

The key part here appears to be:

 2:45.64 fatal runtime error: stack overflow

The fans whirr down and the build finishes with this error. This will need more investigation. But I really will need to leave this one until tomorrow.

You can read all of my gecko-dev diary posts on my Gecko-dev Diary page