focal-armhf fails on Ubuntu 20.04.1 AMD64 host

[nstuardod]

I'm trying to build wkhtmltopdf for an armhf device running Ubuntu 20.04.1 (Raspberry Pi 3). The build machine is running the same distro and version. After installing the required packages (docker.io, python-yaml, p7zip-full and git, obviously) and syncing both qt and wkhtmltopdf repos (master branch), I used the following command line to perform the build process:

$ ./build package-docker focal-armhf ../wkhtmltopdf

First issue: apt-get crashes (segmentation faults) while setting up the build environment.

Unpacking libfreetype6-dev:armhf (2.10.1-2ubuntu0.1) ...
Selecting previously unselected package uuid-dev:armhf.
Preparing to unpack .../50-uuid-dev_2.34-0.1ubuntu9.1_armhf.deb ...
Unpacking uuid-dev:armhf (2.34-0.1ubuntu9.1) ...
Selecting previously unselected package pkg-config.
Preparing to unpack .../51-pkg-config_0.29.1-0ubuntu4_armhf.deb ...
Unpacking pkg-config (0.29.1-0ubuntu4) ...
dpkg-deb: error: tar subprocess was killed by signal (Segmentation fault), core dumped
dpkg: error processing archive /tmp/apt-dpkg-install-aeY87l/52-libfontconfig1-dev_2.13.1-2ubuntu3_armhf.deb (--unpack):
 dpkg-deb --control subprocess returned error exit status 2
Selecting previously unselected package libjpeg-turbo8:armhf.
Preparing to unpack .../53-libjpeg-turbo8_2.0.3-0ubuntu1.20.04.1_armhf.deb ...
Unpacking libjpeg-turbo8:armhf (2.0.3-0ubuntu1.20.04.1) ...
Selecting previously unselected package libjpeg-turbo8-dev:armhf.
Preparing to unpack .../54-libjpeg-turbo8-dev_2.0.3-0ubuntu1.20.04.1_armhf.deb ...
Unpacking libjpeg-turbo8-dev:armhf (2.0.3-0ubuntu1.20.04.1) ...
Selecting previously unselected package libpthread-stubs0-dev:armhf.
Preparing to unpack .../55-libpthread-stubs0-dev_0.4-1_armhf.deb ...
Unpacking libpthread-stubs0-dev:armhf (0.4-1) ...
dpkg: error processing archive /tmp/apt-dpkg-install-aeY87l/55-libpthread-stubs0-dev_0.4-1_armhf.deb (--unpack):
 dpkg-deb --fsys-tarfile subprocess was killed by signal (Segmentation fault), core dumped
Selecting previously unselected package libssl-dev:armhf.
Preparing to unpack .../56-libssl-dev_1.1.1f-1ubuntu2_armhf.deb ...
Unpacking libssl-dev:armhf (1.1.1f-1ubuntu2) ...
Selecting previously unselected package xorg-sgml-doctools.
Preparing to unpack .../57-xorg-sgml-doctools_1%3a1.11-1_all.deb ...

So, I started downgrading the qus image: d5.0 crashes with apt-get complaining of invalid signatures, however d4.2 succeeds so I kept using that version.

Second issue: After a long wait, the build process finally fails because QtWebKit was not built:

/usr/bin/ld: cannot find -lQtWebKit

Same issue as #76 but this is from a clean build. Is this failure related to the branch I'm using?

[ashkulz]

@nicst35: I think it looks like the same qemu bug that produces broken images for Raspbian Buster, can you apply the same workaround and see if it helps?

[nstuardod]

Hi @ashkulz

Just to check if the build script is using the right qemu, I patched shell(cmd, cwd) to see what is actually doing:

def shell(cmd, cwd=None):
    message(cmd)
    ret = subprocess.call(cmd, shell=True, cwd=cwd)
    if ret:
        message('%s\ncommand failed: exit code %d' % (cmd, ret))
        sys.exit(1)

Without any workaround, it appears the focal-armhf target is already using 32-bit QEMU so applying the workaround does no effect because of this (build, line 335):

if target['platform'] not in ('linux/amd64', 'linux/386'):
    # workaround https://bugs.launchpad.net/qemu/+bug/1805913 for 32-bit targets
    target['qemu'] = 'linux/amd64' if target['platform'] not in ('linux/arm/v5', 'linux/arm/v7') else 'linux/386'

This is what the script does on my machine

docker pull --platform linux/386 aptman/qus:latest
...
docker run --rm --privileged aptman/qus:latest -- -r
cat ./qemu-binfmt-conf.sh | sh -s -- --path=/qus/bin -r
docker run --rm --privileged aptman/qus:latest -s -- -p
cat ./qemu-binfmt-conf.sh | sh -s -- --path=/qus/bin -p --suffix -static
Setting /qus/bin/qemu-alpha-static as binfmt interpreter for alpha
...
docker pull --platform linux/arm/v7 ubuntu:focal
docker build -f docker/Dockerfile.focal --build-arg from=ubuntu:focal --build-arg jpeg=libjpeg-turbo8-dev -t wkhtmltopdf/0.12:focal-armhf docker/

And then, even if no SIGSEGV is raised, libc-bin setup fails with Allocating guest commpage: Operation not permitted.

[ashkulz]

You're right, I forgot about the part. From a previous log where it was successful, it seems the following SHA256 of aptman/qus was used:

latest: Pulling from aptman/qus
947be6ecc5f4: Already exists
8464b14bbf96: Already exists
86eee92003c9: Already exists
3810c5e368ec: Already exists
56438b5e5595: Already exists
Digest: sha256:b7b452445c7f9ff2c4c1d88f1867dfebb71a50e1240f63586de8afaffb9ced67
Status: Downloaded newer image for aptman/qus:latest

Maybe try to use that? Otherwise, I'm not really sure what the issue could be.

[nstuardod]

After a long wait and switching to a release branch, I could get a working build using qus:d4.2 for the docker build environment, and commits 6a57c14 (0.12.6) and ccdfd25996 (wk_4.8.7) of wkhtmltopdf and QT, respectively. (Since it includes the QT patch to avoid arithmetic exceptions, I'm attaching the generated .deb in a .zip in case someone finds it helpful) wkhtmltox_0.12.6-1.focal_armhf.deb.zip

Maybe try to use that? Otherwise, I'm not really sure what the issue could be.

I will try and report the results.

[nstuardod]

And yep, it builds with b7b452445c7f9ff2c4c1d88f1867dfebb71a50e1240f63586de8afaffb9ced67

[ashkulz]

Which Qt patch are you talking about? Also, not sure if we should report an issue about qus:latest not working for armhf.

[nstuardod]

ccdfd25996: Fix artihmetic exception when using non-scalable fonts.

[ashkulz]

I'm closing this as your PR #86 was merged :+1: