ARM / ARM64 compilation issues #470
Labels
confirmed-bug
Issues with confirmed bugs
Comments
|
Gtk3 is still a WIP on box64. I would only attempt it natively... specially on an open source project. |
Juding by this error I thing python3 v3.8.0 is required, but on my ubuntu 16.04 box is 3.5.2 installed Maybe try to build arm version on newer Ubuntus, as far as I remember for arm we use 18.04 |
|
Moved issue to |
Yea, I remember briefly trying ubuntu:22.04 and there were many more errors, so I stuck with the version the instructions said.. I will try 18.04 tomorrow. |
|
It still hasn't failed, but some unexpected output has come up: I will follow up with the Dockerfile I made for arm, based on the og of this repo, after i'm done with the compilation on 18.04. |
|
Alrighty, it failed in a much different way now To produce these results I created the following dockerfile |
host arch should NOT be returning as aarch64... that is determined here from chromium source well technically it used to just return aarch64.. but that bug was fixed 4 years ago https://chromium.googlesource.com/chromium/src/build/+/15ff94c12fba191a9638daec370b26881d8453cf |
Uname, even the python module on: I know that as a matter of fact because of one of my own projects.
(It can't POSSIBLY be using such an old version) |
bill88t
changed the title
|
I'll try to take a look at the build script as well, but I got lost quite quickly in it (tried to modify it to compile directly on arch Linux - silly me). |
modify /core/Common/3dParty/v8/v8/DEPS ： |
|
I have successfully completed the compilation of the server for aarch64 ，here is compilation log， and It seems that I didn't find any obvious errors on it. but it failed on start |
|
I can confirm this error Checked it only the amazon arm instance with ubuntu 18.04 Seems that currently our code is not fully ready to a compilation on arm, I've created issue 57301 |
ShockwaveNN
changed the title
Unrecognized host arch: aarch64 error while compiling on arm
I am gonna do this tonight. |
|
@bill88t If you have normal amd64 pc, you can use |
|
|
|
@bill88t |
|
Ok, I've been building for like 45 minutes without errors. I had to kill it though, as I changed some things in the Dockerfile, etc. Looks alright so far though. |
|
Oh, the output got larger than 1MiB, so I see nithing. But I'm compiling for 2 hours now and from the processes running ( |
|
A pi compilation fails at like 5 hours |
|
Guys, do you really need to compile it from source for several hours? |
Oh, but watch your temperatures. I'm running overclocked Pi 4 4GB all the time, but I have active cooling on it. Also, that finished compilation was only qt |
|
@ShockwaveNN Are DesktopEditors available for |
|
Oops, sorry, my bad A little mess in my head, since usually people try to build our source for DocumentServer |
|
To be honest, a pi4 overclocked it's a decent compiling pc. Of course, you can't compare it with modern x86_64 hw. Hopefully this project will support and provide aarch64 binaries sooner or later. |
|
Uhm, today I had to setup qemu to work with docker (for another thing) to sum it up
I will try with onlyoffice hopefully tonight |
Yup, that's how I have it setup. Compiling on the rpi4 (even if I had an SSD instead of a hdd) is a chore, so I have that setup on my main PC. |
|
I have gotten the arm64 build environment working on my x64 server a few days now. And made further progress. The only warnings i'm running at now are: Which prolly are just clang-10 vs clang-12 |
|
So. I'll probably have some free time now. The route I will take will be like this:
I'll see how will my plan go, bu I've already been successful in emulating arm64 with qemu and docker buildx. |
It's way too much, please take a look at https://github.com/bill88t/build_tools-arm64 first. Also, to sum up the scripts: -> tools/linux/automate.py -> make.py -> scripts/develop/develop.py -> tools/linux/automate.py -> make.py -> scripts/core_common/make_common.py -> scripts/core_common/modules/boost.py -> tools/linux/automate.py -> make.py -> scripts/core_common/make_common.py -> scripts/core_common/modules/cef.py -> tools/linux/automate.py -> make.py -> scripts/core_common/make_common.py -> scripts/core_common/modules/icu.py -> tools/linux/automate.py -> make.py -> scripts/core_common/make_common.py -> scripts/core_common/modules/openssl.py -> tools/linux/automate.py -> make.py -> scripts/core_common/make_common.py -> scripts/core_common/modules/v8.py -> scripts/core_common/modules/v8_89.py and this is where i'm at |
|
Successfully built v8. We can finally move on. |
|
After a lot of fiddling with the script shebangs to make the stdout unbuffered, I have determined the next error. At tools/linux/automate.py -> make.py -> scripts/build.py -> make() -> make_pro_file("makefiles", "build.pro") -> base.cmd_and_return_cwd(base.app_make(), ["-f", makefiles_dir + "/build.makefile_" + file_suff, "-j" + str(multiprocessing.cpu_count())]) The error: A "complete" (this layer's only) log: Keep in mind, it's a 4mb log, your pc may seriouly lag out tryna open it. |
|
my guess is that as we are building v8 for arm64, it doesn't like: it being put there. it prolly only likes linux_64 |
|
That didn't work After a lot of work I have traced back the current error to It gets built by To have these files in the filesystem you have to reach the point where At this point I do not know why the v8 header is missing in that directory, I have it under I will try copying it (along with the rest of |
|
-I parameter missing |
|
Yea, but those options are specified by the generated qmake makefile and hence the source .pro files. |
|
did fix the v8.h not found errors by patching v8.pri with moved a bit up ahead and errored on why is all it so broken |
|
Ah that was just boost being stored in the wrong dir name, fixed that. Now errored 5 hours after that at Because my cef stuff was borked. |
|
And after a lot of npm, it failed at: I am not a nodejs guy, and I have no idea how npm works, so this is probably gon take a very good while to understand what happened. |
|
Successfully built it for the first time, however all of libicu (libicudata.so libicudata.so.52 libicudata.so.52.1 libicui18n.so libicui18n.so.52 libicui18n.so.52.1 libicuuc.so libicuuc.so.52 libicuuc.so.52.1) files are missing on the target. |
|
Fixed icu, now the app fails to start with: This appears to be a xcb - qt version mismatch, which means I should somehow make it build along with qt. |
|
Got it. Had to launch it with For the 2nd time, this time natively, welcome to Raspberry Pi, Onlyoffice. However it segfaults whenever I try to do pretty much anything.. For anyone who wants to see for themselves, https://github.com/bill88t/build-tools-arm64 it's only a 15hr compile |
Sorry, but I really don't know what to do, I don't sure that our team has enough resources to find out reasons of segfaults by ourselfs |
Problem in QT Threads + CEF. |
|
Here, have a gdb run. |
|
To fix segfault
This way: linux_arm64 { }
in all *.cpp files fix error: “type 'double' cannot be narrowed to 'int' in initializer list [-Wc++11-narrowing] “- by adding “static_cast( ) “ something like this way |
|
Well 1 could be done in yet another base.replaceinfile right before the build as an arm64-specific patch. |
|
Is it possible to merge these changes to the repo? |
|
Nope. They are out-of-date, and broken regardless. |
|
Any update? |
|
any updates? |
|
No @kde-yyds. I will not be working on this issue. The progress is there. |
This was referenced Nov 7, 2023
Closed
|
Hi everyone, here's how to compile code for the ARM architecture. I have already written the entire process to automate it. git clone --branch release/v8.1.0 https://github.com/fernfei/build_tools
cd build_tools/tools/linux
./automate.py --platform="linux_arm64"ps. Must be ubuntu:18.04 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue is unique.
Operating System
Linux
Version information
7.1.0
Expected Behavior
Compile
Actual Behavior
Reproduction Steps
Using ubuntu 16.04 container with the instructions of onlyoffice build_tools git repo
Opened the container, apt update && apt upgrade -y && apt install -y python
and ran the
./automate.py desktopAdditional information
Seeing as ONLYOFFICE/DocumentServer#152 issue being closed, I decided to try compiling onlyoffice natively again to see if it actually would, it actually now stops on some chromium depot_tools checks, for missing stuff. It's promising though!
Compilation in ubuntu 16.04 (as instructed by the onlyoffice buildtools) container from my oveclocked Pi400.
It failed something like 2 hours in, which is not bad (except for my mental health)
Also tried on the 7.1.0 deb via box64 and gtk3 lib at hand with the same results as ONLYOFFICE/DesktopEditors#270.
The text was updated successfully, but these errors were encountered: