Problems when compiling on armv8 platform. about packaging HOT 16 CLOSED

@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?

from packaging.

@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.

from packaging.

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?

from packaging.

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 👍

from packaging.

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.

from packaging.

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.

from packaging.

@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.

from packaging.

@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/

from packaging.

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

from packaging.

@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

from packaging.

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.

from packaging.

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.

from packaging.

@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 👍

from packaging.

@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.

from packaging.

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

from packaging.

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.

from packaging.