Support cross-compile on aarch64 platform #4271
Conversation
|
hello, |
|
oops, sorry, i didn't recognized, that i used the unpatched package.mk file... with the patched version i get the following error: |
|
We have no issue with the change in this PR but we do not support (or have any plans to support) building LE images on arm hardware; we support cross-compile of arm images from an x86_64 build host only. The -m64 error means that something is not setting the right build flags (CFLAGS probably). This is a "working as designed, so not a bug" issue so please take further commentary to the forums. Thanks. |
|
ok... sorry for my comments here. |
|
I can adjust the patch to be able to compile also on armv7 platforms. My experience is that other things will fail but at least solving one problem at a time. |
so i switched to a PC and cross-compile the software for the RPi. EDIT: i corrected username. |
|
To be clear, we have no objections to people finding/fixing the issues that prevent native compile on other architectures, but if there's more than a couple of nip/tuck changes needed it would be best to queue everything up and submit a single superset PR so our build-system maintainers can understand the overal picture and critique the summed changes. Sending macro changes over many PRs results in people wondering "where is this going?" and "when does this end?" and the natural and correct response will be to refuse the changes. NB: I'm still not sure why anyone would ever want to compile LE images on ARM boards; it's going to be painfully slow compared to any x86_64 chip from the last decade :) |
|
For me personally as I for not have a PC (and don't plan to buy any) compiling on arm64 is much easier than buying a cloud instance (and paying for it). If it is could compile over night in the first instance would be great... |
|
For the record, what are you building on (hardware and distro)? |
|
Rockpro64 armbian buster. My point was about multiple commits was that I may not be able to finish the job (time commitments), I can get at least few fixes out and then someone else (or me) can bridge the gap. |
|
Also to get it to compile I had to add qemu-user-binfmt, ld.so and libc for x64 because rk utilities are on x64 only. Because there is no aarch64 compiler for arm platform, I think adding arm might be more difficult so I will not include it in those patches. |
|
btw, I noticed |
chewitt
changed the title
catalinii
force-pushed
the
master
branch
2 times, most recently
from
b8cea87
to
e727734
Compare
|
I cleaned a bit the patches and I think is ready to merge. Please let me know if you have other comments. Do you think there is a point to add to the compilation wiki steps for arm64? |
catalinii
changed the title
catalinii
force-pushed
the
master
branch
3 times, most recently
from
b0eee12
to
e407a33
Compare
MilhouseVH
dismissed
their stale review
Scope changed considerably since original review
catalinii
force-pushed
the
master
branch
2 times, most recently
from
f1bc3a5
to
8fd9201
Compare
|
Updated. Included also the dependencies needed for the build. Can you review that as well ? |
scripts/checkdeps
Outdated
| @@ -122,6 +122,17 @@ if [ -n "${DISTRO_DEPS_PKG}" ] ; then | |||
| deps_pkg+=(${DISTRO_DEPS_PKG}) | |||
| fi | |||
|
|
|||
| # aarch64 dependencies | |||
| if [ "${MACHINE_HARDWARE_NAME}" = "aarch64" ]; then | |||
There was a problem hiding this comment.
scripts/checkdeps does not source config/options. It did until fairly recently, see db6d111 so you'd need to go down that rabbit hole and fix that issue before being able to source config/options again. In this case we only call scripts/checkdeps once per build, so use $(uname -m) rather than try to source config/options.
What happens if/when the soname versions (.2, .6 etc) change?
Is building qemu-x86_64 and qemu-user-binfmt an option?
There was a problem hiding this comment.
I replaced with uname -m. I think it is clear that way considering that all the places checkdeps is already called already calls config/options before. As a result I have changed the commit.
Related to libc:
This is required by the rockchip utilities part of rkbin package. Considering that may not change very frequently I am not sure this will be an issue mid term.
Compiling libc for x86_64 always may be an overkill as we need to use an x86_64 gcc.
|
@MilhouseVH, please let me know if you have further questions related to the commit ? |
|
@catalinii so with this PR, what state are we in, are you able to build an In terms of the build system config and scripts changes, I don't have much of an issue - I am a bit uncomfortable with specific soname versions being hard coded in scripts/checkdeps as that's likely to bite us at some point (maybe we'll have to support multiple versions?) but if there's no better solution then... meh. For the Rockchip, u-boot and other aarch64/linaro changes I can't really comment as that's not an area I'm familiar with - @chewitt, @jernejsk, @Kwiboo any thoughts? |
|
I was able to build an older version of the repository (@Kwiboo's mainline-rockchip branch). I tried to build the current master, but that fails compiling mali-midgard and is failing on x86 as well. |
|
@catalinii Copy from a working x86_64 system: *********** FAILED COMMAND *********** Makefile:12: recipe for target 'image' failed |
|
I did not carefully read the previous message (where it says that this should be done manually). Added these files and the build started. :) If can resolve the issue of distributing the build between multiple devices (cluster), this will allow to build faster than on a PC and with less power consumption :) |
|
After fixing some small things, managed to build images for all AW + RK + AML platforms. Now I will test the operation of the build images. Thanks for the initial commit and a kick in the right direction. :) By the way, the build time on RK3399\4Gb RAM + NVMe (nanopc-t4) is approximately equal to the build time on a PC i7 in virtual machine mode with parameters of 4 cores, 4GB RAM, 100GB SSD. :) |
|
Are there some improvement needed on top of this commit ? |
|
I will describe what I changed, and you will decide for yourself what and how to change in the commit. :)
deps_pkg+=(qemu) https://github.com/LibreELEC/LibreELEC.tv/pull/4271/files#diff-02608e660344401b79d29a5733e20ab6R133
The rest I didn't change and the aarch64 build was successful for all the platforms I use (Allwinner + Rockchip + Amlogic). Images collected on ARM RK3399\S922X work without problems. I checked the build of Addons, almost all of them are collected (except for 12 Addons), but I haven't checked their work yet. It would be good to automate the addition of two libraries for QEMU, for example, as an archive with auto-extracting to the right place, as in the source code. |
|
Fixed the u-boot-tools build. "Side" effect when switching to build on ARM, the error of building several packages for aarch64 (Pillow simplejson pycryptodome) disappeared. Now the arm and aarch64 images are identical. :) |
|
The build for arm (32bit) passed without errors. The full build time (along with downloading the source code) on the Odroid N2 + USB SSD was 4 hours and 50 minutes. |
I did not see (3) in my environment |
|
fix for u-boot-tools make_host() { if [ "${MACHINE_HARDWARE_NAME}" = "aarch64" ]; then |
|
IMHO this patch contains "extra" elements that are not directly related to the build system itself (they change the data for the build of a specific platform RK3399). |
|
Needs a rebase. |
|
@MilhouseVH, dropped the other 2 patches and rebased on the current master Thanks |
|
nobody complained further so merge it and fix possible problems if they appear |
|
Thanks @CvH ... I will test this further and provide new fixes if that is the case |
This commit enables building openssl on another systems instead of x86_64 (eg. arm)