ping @pelwell

It seems to work, but we should probably retain the old method for platforms that aren't Debian-based.

Any concerns, @popcornmix?

I think this makes sense. The standard repo toolchains will work just fine (and in fact are required for aarch64 builds).

The rest of the instructions assume apt, so I withdraw the request to not delete the previous version.

The other thing is the documentaton specifically says that it uses Ubuntu and already uses APT so perhaps if we dont want to use the repo tools then we should also change the other instructions or move to a container like build to have a common environment.

While I personally like the idea of using Docker or Podman, i dont think most people wont so for the time being I think we should continue to target Ubuntu (and Debian derivatives)

And in the case we do want to add support for other distros such as Fedora or Arch. I would not expect it to be that much of a problem to have distro specific instructions as most of the build is distro agnostic.

ping @native-api I think this PR might mean that the CCache instructions (added in #1630 ) could be removed too?

@lurch Yes, Apt packages use tarballs under the hood to hold files which preserve timestamps upon restore. So the CCache workaround would no longer be needed if Apt packages are used instead of a Git checkout.

@lurch I would still double-check though. It's possible that the packages create something on the fly (like symlinks) in the postinstall step which may or may not have the same timestamps and/or confuse Ccache.

I would like to confirm @native-api findings as when i install the compiler on my Debian Sid installation i get a binary that was modified days ago not minutes. So i have reason to believe that ccache will not complain.

ryan@think:~$ ls -l $(whereis arm-linux-gnueabihf-gcc | awk '{print $2}')
lrwxrwxrwx 1 root root 26 Jul 21 09:16 /usr/bin/arm-linux-gnueabihf-gcc -> arm-linux-gnueabihf-gcc-10

Is there any guarantee that --install-recommends will always install all the packages needed? Might be better to be explicit? 🤷

Also, do you want to remove the ccache parts?

--install-recommends will work unless the maintainer removes the package from the meta-package so maybe that should be revisited.

i have left the ccache part as I was not sure what was wanted, but i presume it is not needed anymore as we have confirmed the binaries hold their timestamp. I will work on that now.

Would there be benifit by using the build-essential meta-package as it is quite static and contains libc6-dev, make, and the host platform compilers which will be needed for menuconfig which is talked about later.

A new debian or ubuntu install will not contain the host gcc and the meta package will only install the target gcc. With this configuration then the instructions at https://github.com/raspberrypi/documentation/blob/master/linux/kernel/configuring.md are missing information.

Hmmm, now that the "Install toolchain" section is just sudo apt install crossbuild-essential-armhf it probably makes sense to just include that in the "Install required dependencies" section? (i.e. append crossbuild-essential-armhf to the end of the other "apt install" line)

Looking at it, i will agree it would just be better to be all one command

Would there be benefit for adding a note for non Debian/Ubuntu users about what minimum version of the cross compiler that they should install?

The page already talks about running Ubuntu inside a VM, so probably not any need for non Debian/Ubuntu instructions? 🤷

perhaps but the instructions are almost completly distro agnostic, if we just gave a list of generic packages like...

 * git
 * bc
 * bison
 * flex
 * gcc-armhf >= 4.9.5

for those who have like a alpine build server of sorts. This is kinda far fetched so if it was wanted then i guess another pull request will do. might as well keep this PR clean.

The more detailed the documentation is (e.g. listing specific versions of specific packages), the more of a maintenance burden it becomes if / when it has to change 😉

I suspect somebody setting up an Alpine Linux build server will already have the technical know-how to convert the Ubuntu instructions to their distro of choice?

I presume so :D

These changes to the instructions are needed for the 5.9 kernel tree, otherwise the build complains about using an old compiler. It probably ought to be merged as soon as possible.

Going to merge this, think it makes sense as is.