Problems when compiling on armv8 platform.

[BlindingDark]

1

I tried to build for arm64, but some compilation errors have occurred.

error: cast from 'JSC::JSCell*' to 'int32_t {aka int}' loses precision [-fpermissive]

It seems to be qt4 own bug. (http://lists.openembedded.org/pipermail/openembedded-core/2014-November/098726.html)

I tried change int32_t to int64_t, solved the cast problem but caused another problem: It can't pass COMPILE_ASSERT at src/3rdparty/webkit/Source/JavaScriptCore/runtime/JSGlobalData.cpp:126

// Enough storage to fit a JSArray, JSByteArray, JSString, or JSFunction.
// COMPILE_ASSERTS below check that this is true.
char storage[64];
COMPILE_ASSERT(sizeof(JSArray) <= sizeof(storage), sizeof_JSArray_must_be_less_than_storage);

So I change char storage[64]; to char storage[80];, and compiled successfully.

But when I tried to run it, a segmentation error occurred. I tried to debug it with gdb, seems to be about JSValue or something else...

I don't know how to solve it. I am not familiar with c++. 😢

---

packaging version is 0.12.5-1 wkhtmltopdf version is 4.8.7 build command I am using is

./build package-docker arm64 ./path/of/wkhtmltopdf

Here is the build.yml

# prefix used in determining full image name in "docker-images" and "compile-docker"
docker-prefix: wkhtmltopdf/packaging:0.12_

# command to run for enabling foreign-arch support in currently running kernel (>= 4.8)
qemu-cmd:      docker run --rm --privileged fkrull/qemu-user-static enable

# all targets supported by the docker-related commands, keys are as follows:
#
#   source:         Dockerfile used to build image
#   output:         one of deb, rpm, tar or 7z
#   args:           build-time docker args (optional)
#   arch:           used as arch specified to fpm (for deb or rpm output)
#   depend:         dependent packages specified to fpm (for deb or rpm output)
#   qt_config:      override the qt configuration used for building Qt (optional)
#   cross_compile:  use given prefix for cross-compilation (optional)
#   qemu:           set to true if qemu emulation is required (optional)
#
docker-targets:
  arm64:
    source: docker/Dockerfile.debian
    args:
      from: arm64v8/debian:stretch
    output: 7z
    qemu:   true
    arch:   arm64
    depend: >
      ca-certificates
      fontconfig
      libc6
      libfreetype6
      libjpeg62-turbo
      libpng16-16
      libssl1.1
      libstdc++6
      libx11-6
      libxcb1
      libxext6
      libxrender1
      xfonts-75dpi
      xfonts-base
      zlib1g

# Qt configure arguments
qt-config:
  common: >
    -opensource
    -confirm-license
    -fast
    -release
    -static
    -graphicssystem raster
    -webkit
    -exceptions
    -xmlpatterns
    -system-zlib
    -system-libpng
    -system-libjpeg
    -no-libmng
    -no-libtiff
    -no-accessibility
    -no-stl
    -no-qt3support
    -no-phonon
    -no-phonon-backend
    -no-opengl
    -no-declarative
    -no-script
    -no-scripttools
    -no-sql-ibase
    -no-sql-mysql
    -no-sql-odbc
    -no-sql-psql
    -no-sql-sqlite
    -no-sql-sqlite2
    -no-mmx
    -no-3dnow
    -no-sse
    -no-sse2
    -no-multimedia
    -nomake demos
    -nomake docs
    -nomake examples
    -nomake tools
    -nomake tests
    -nomake translations
  debug:
    -debug
    -webkit-debug
  docker: >
    -silent
    -xrender
    -largefile
    -iconv
    -openssl-linked
    -no-javascript-jit
    -no-rpath
    -no-dbus
    -no-nis
    -no-cups
    -no-pch
    -no-gtkstyle
    -no-nas-sound
    -no-sm
    -no-xshape
    -no-xinerama
    -no-xcursor
    -no-xfixes
    -no-xrandr
    -no-mitshm
    -no-xinput
    -no-xkb
    -no-glib
    -no-gstreamer
    -no-icu
    -no-openvg
    -no-xsync
    -no-audio-backend
    -no-sse3
    -no-ssse3
    -no-sse4.1
    -no-sse4.2
    -no-avx
    -no-neon
  mingw-w64: >
    -silent
    -openssl-linked
    -no-reduce-exports
    -no-rpath
    -no-pch
    -xplatform win32-g++-4.6
  macos-carbon: >
    -silent
    -reduce-exports
    -no-framework
    -no-dwarf2
    -openssl-linked
    -largefile
    -no-rpath
    -carbon
    -platform unsupported/macx-clang
  macos-cocoa: >
    -silent
    -reduce-exports
    -no-framework
    -no-dwarf2
    -openssl-linked
    -largefile
    -no-rpath
    -cocoa
    -platform unsupported/macx-clang-libc++
  msvc: >
    -mp
    -qt-style-windows
    -no-style-cleanlooks
    -no-style-windowsxp
    -no-style-windowsvista
    -no-style-plastique
    -no-style-motif
    -no-style-cde
    -openssl-linked

# docker image which provides fpm
fpm-image:      wkhtmltopdf/fpm:20190502

# parameters for building linux packages via fpm (deb/rpm)
fpm-params:
  name:         wkhtmltox
  description:  convert HTML to PDF and various image formats using QtWebkit
  license:      LGPLv3
  vendor:       wkhtmltopdf
  maintainer:   Ashish Kulkarni <ashish@kulkarni.dev>
  url:          https://wkhtmltopdf.org/
  prefix:       /usr/local
  category:     utils

[ashkulz]

Unfortunately, I don't have access to an armv8 system or the time to debug this. I'd suggest you look at patches made for qt4 in other distributions and/or BSDs, as they may give you an idea of what may work. I suspect changes in JSValueInlineMethods.h is required.

[penzhaohui]

You could try the docker image multiarch/qemu-user-static, which is to enable an execution of different multi-architecture containers by QEMU. Currently, I also expect one complied package for arm64v8/debian:stretch platform.

[ashkulz]

@penzhaohui: If you see fkrull/qemu-user-static is used already which speeds up things on Linux 4.8+. As I said earlier, I don't have time to debug this ... happy to review if you find/develop any patches.

[penzhaohui]

@ashkulz . Fine, thanks for your response. I will have a try. Just for reference, there are some available packages for ARM architecture.

http://tardis.tiny-vps.com/aarm/packages/w/wkhtmltopdf/

[ashkulz]

@penzhaohui: those look to be the unpatched Qt5 builds, not Qt4 builds. I haven't had time to port the patches to Qt5 yet.

[penzhaohui]

@ashkulz Thanks a lot! I got the same error as @BlindingDark described, and also compare the project structure between qt4.8.7 and qt5, looks like there is huge difference.

https://download.qt.io/archive/qt/ https://github.com/qt/qtbase

[penzhaohui]

The file wkhtmltox_0.12.5-1.stretch_arm64.deb could be built after perform the following 2 changes.

1. Change int32_t to int64_t in the file: qt\src\3rdparty\webkit\Source\JavaScriptCore\runtime\JSValueInlineMethods.h
2. Change char storage[64]; to char storage[128] in the file: qt\src\3rdparty\webkit\Source\JavaScriptCore\runtime\JSGlobalData.cpp

However, it does not work. The following describes how it does not work in arm64v8 docker container. Notes: Host machine is x86_64.

# wkhtmltopdf -V 
wkhtmltopdf 0.12.5 (with patched qt)
# wkhtmltopdf http://www.baidu.com ./baidu.pdf
Loading pages (1/6)
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

And my build meta file.

docker-targets:
  stretch-arm64v8:
    source: docker/Dockerfile.debian
    args:
      from: arm64v8/debian:stretch
    output: deb
    #qemu:   true
    arch:   arm64
    #qt_config:      armv8-64
    #cross_compile:  aarch64-linux-gnu-
    depend: >
      ca-certificates
      fontconfig
      libc6
      libfreetype6
      libjpeg62-turbo
      libpng16-16
      libssl1.1
      libstdc++6
      libx11-6
      libxcb1
      libxext6
      libxrender1
      xfonts-75dpi
      xfonts-base
      zlib1g

Again, I also tried other compiler - arm-linux-gnueabihf-g++, but get some other error related to compile environments.

[soleson]

For others running into this issue, I was able to successfully compile for aarch64 (amd64v8) architecture that we needed for an AWS EC2 Instance (Amazon Linux 2 AMI).

The major issue with the compilation is not those specific lines casting 'JSC::JSCell*' to 'int32_t {aka int}'. The aarch64 architecture is not covered in the current qt4 submodule packaged with the wkhtmltopdf source. Specifically, around line 1003 of file: src/3rdparty/webkit/Source/JavaScriptCore/wtf/Platform.h qt4 evaluates the CPU architecture to determine whether WTF_USE_JSVALUE64 = 1 or WTF_USE_JSVALUE32_64 = 1. We need the former for compilation to finish without that loss of precision caused during the cast operation mentioned above. In our one-off build, we simply needed to add #define WTF_USE_JSVALUE64 1 just before those if blocks. A better solution would be to add AARCH64 to the list of CPU architectures being checked.

Hopefully, this helps others.

Credit to:

• https://tech.mybuilder.com/compiling-wkhtmltopdf-aws-lambda-with-bref-easier-than-you-think/
• https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/

I'd be happy to contribute the compiled binary, if that would be helpful.

Happy coding.

[ashkulz]

@soleson can you add a PR with your changes to the wkhtmltopdf/qt repository? I'm not averse to merging the changes if they aren't very invasive :+1:

[soleson]

@ashkulz done. I've submitted the PR. This is my first PR to any projects, so hopefully, it's done to meet established standards. I'll keep an eye out in case further changes are needed.

[ashkulz]

@soleson: I've merged the PR, thanks for the contribution!

@BlindingDark: can you check if you're now able to build a package with the latest qt being checked out?

[BlindingDark]

@ashkulz 🤒 I was hospitalized and I will reply to you in a few days.

[ashkulz]

Take care, @BlindingDark! I hope all is well.

I used a quick-and-dirty approach to make a trial build, and it produced a package. Can someone else too try and see if that package works?

[ashkulz]

@BlindingDark @penzhaohui @MrRSK @pavel-odintsov @romaricdrigon: just a heads up, the next release will have the following builds supported (due to the Qt patches contributed by @soleson):

• amazonlinux2-aarch64
• bionic-arm64
• buster-arm64
• centos7-aarch64
• centos8-aarch64
• focal-arm64
• stretch-arm64
• xenial-arm64

None of these will be built by default, as it takes 5-6 hours to build each target (as it is done via emulation) -- you should be easily be able to build them on your own once #66 is merged.

[ashkulz]

Please see the latest release which has packages for all the targets mentioned above. Please add a comment if you face any problems in using the packages :+1:

[ashkulz]

A release candidate for the 0.12.6 release is now available for download, which should contain changes which possibly address this issue.

Would appreciate downloading the package and reporting back if any issues are encountered during testing. Assuming all goes well, I plan to release 0.12.6 on the 2-year anniversary of the previous release i.e. June 11, 2020.