[Bug]: several boot loaders doesn't compile when switching host to Noble

[igorpecovnik]

What happened?

How to reproduce?

./compile DOCKER_ARMBIAN_BASE_IMAGE="ubuntu:noble"

Branch

main (main development branch)

On which host OS are you running the build script and observing this problem?

Ubuntu 24.04 Noble

Are you building on Windows WSL2?

• [ ] Yes, my Ubuntu/Debian/OtherOS is running on WSL2

Relevant log URL

https://paste.armbian.com/duyodikako

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[github-actions[bot]]

Jira ticket: AR-2402

[The-going]

On ubuntu-22.04 all build target done, but 1 bpi-f3 fail On ubuntu-24.04 12 target fail

Did I understand correctly?

[igorpecovnik]

On ubuntu-22.04 all build target done, but 1 bpi-f3 fail

yes

On ubuntu-24.04 12 target fail

yes

[The-going]

Currently, there is an old and bad external compiler mechanism in the build system. It's bad because everything is loaded, but you only need to download the necessary version for the architecture. Or use one that already exists with the user. That is, just specify the path to the folder.

If you approve, I will implement it. The riscv64 compiler can be taken here: http://archive.spacemit.com/toolchain/

https://archive.spacemit.com/toolchain/spacemit-toolchain-linux-glibc-x86_64-v1.0.0.tar.xz or https://archive.spacemit.com/toolchain/spacemit-toolchain-linux-glibc-x86_64-v0.3.3.tar.xz

After that, some special cases can be solved using an external compiler from buildroot or another, or self-assembled.

[ColorfulRhino]

I believe the issue here is less "how can we stay on the old jammy hosts" but more "what needs to be updated to get the old stuff running on the new noble system"?

First thing to collect is the info, what do the failing u-boots have in common? A specific version?

Edit:

• 1x 2022.04 (nanopi-neo3)
• 5x 2022.07
• 1x 2017.09 vendor (raxda-e25)

[ColorfulRhino]

I figured it out :) Semantic versioning 🎉 PR soon.

[amazingfate]

I just fixed uboot of rock5b building with -Werror: https://github.com/radxa/u-boot/pull/81 But there are so many rockchip's vendor uboot sources.

[ColorfulRhino]

Fix: https://github.com/armbian/build/pull/6867

But OrangePi5 U-Boot building fails because it's using a vendor U-Boot from Xunlong. I have pinged @efectn

@igorpecovnik actually, most of those should also fail compiling even on jammy ./compile DOCKER_ARMBIAN_BASE_IMAGE="ubuntu:jammy" since it's setuptools not GCC causing this.

[igorpecovnik]

There are several others: https://github.com/armbian/os/actions/runs/9769962830/attempts/5

[ColorfulRhino]

Yeah I have noticed Indiedroid Nova failing to build, it's using some external vendor U-Boot. @lanefu You may consider also moving to the default family uboot :)

Next set of fixes: https://github.com/armbian/build/pull/6877

[ColorfulRhino]

Odroid XU4 uses some ancient vendor uboot:

https://github.com/armbian/build/blob/654d208053f60d5793b25ea354df80a8d2116779/config/sources/families/odroidxu4.conf#L10-L13

Doing a short research I could not see that this board is supported by mainline unfortunately. Since I don't have the board myself and the SoC is unknown to me, I can only ping the maintainer to try porting this to mainline using a defconfig and dts. @joekhoobyar Mainline does have support for Odroid XU3 so it may not be too far of a stretch :)