debianhf branch make rpi-all log gives error logs at very end of build process about rpi-img-builder HOT 7 CLOSED

I see now.

That's not going to work as a build host for building arm. The cross compiling bit in the builder is meant for x86_64 based systems. In theory creating the img its self should be fine, but when it comes to compiling the kernel its going to produce ugly code and error out as it did for you above.

This is the reason I created a custom armel img for the Pi4 and use it to bake native kernels.

from rpi-img-builder.

Thanks for the reply. The initial cross compilation of the kernel works beautifully.
Can you clarify why, or under what circumstances a second kernel compilation is required?

I don't understand. When has this ever worked? If someone knows of a way to accomplish this, I'm all ears.

from rpi-img-builder.

I see now.

That's not going to work as a build host for building arm. The cross compiling bit in the builder is meant for x86_64 based systems. In theory creating the img its self should be fine, but when it comes to compiling the kernel its going to produce ugly code and error out as it did for you above.

This is the reason I created a custom armel img for the Pi4 and use it to bake native kernels.

Can you expand a bit on why cross compilation is not functional and indeed not easier to achieve on a more aligned and similar build host architecture (arm64 to armel) than (x86_64 to armel)?

If less problematic, then it's possible of course to switch to x86_64 build host agent, but just curious ...

Thanks!

from rpi-img-builder.

Hmm. Well I appear to be wrong, as I just successfully pulled this off using the master branch. :) I'm thinking there must be a depends missing? Unfortunately what I believe it to be, is not available in Debian / Devuan.

Packages in question: gcc-8-multilib-arm-linux-gnueabi gcc-9-multilib-arm-linux-gnueabi gcc-10-multilib-arm-linux-gnueabi

I'll get back to you on my findings. Just leave this open till I figure it out.

from rpi-img-builder.

Can you expand a bit on why cross compilation is not functional and indeed not easier to achieve on a more aligned and similar build host architecture (arm64 to armel) than (x86_64 to armel)?

If less problematic, then it's possible of course to switch to x86_64 build host agent, but just curious ...

Thanks!

To be absolutely honest with you, I'm not 100% sure why it behaves the way it does inside the chroot. For example, if you install the kernel directly to the board it appears to compile the headers just fine. Inside the chroot it blows up?!

Maybe something is leaking into or out of the chroot and confusing the compilation? Could be the headers are dirty due to compiling a 32bit kernel on a 64bit host? It's a mystery so far.

Its things like this that lead me to just build native most of the time.

from rpi-img-builder.

I will be closing this until a solution presents its self. So far all my searching and testing hasn't amounted to anything.

from rpi-img-builder.

The following commits should resolve this issue: a6b0d71 d86dc99

from rpi-img-builder.