raspberrypi-kernel-headers deb package is missing scripts/dtc/include-prefixes for building dtbo overlays

[gtrainavicius]

Describe the bug
raspberrypi-kernel-headers deb package is missing scripts/dtc/include-prefixes for building dtbo overlays, it should contain symbolic links just like in the linux kernel tree https://github.com/raspberrypi/linux/tree/rpi-6.1.y/scripts/dtc/include-prefixes

Without it, compiling .dtbo files of out of tree kernel module fails, as it can't find the include files.

To reproduce

sudo apt install raspberrypi-kernel-headers
git clone https://github.com/blokaslabs/pisound.git
cd pisound/pisound-module
make
...
  DTCO    /home/patch/work/pisound/pisound-module/pisound.dtbo
/home/patch/work/pisound/pisound-module/pisound-overlay.dts:23:10: fatal error: dt-bindings/gpio/gpio.h: No such file or directory
   23 | #include <dt-bindings/gpio/gpio.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.lib:428: /home/patch/work/pisound/pisound-module/pisound.dtbo] Error 1
...

Expected behaviour
The .dtbo files should compile, here's a local workaround for dt-bindings:

sudo mkdir /usr/src/linux-headers-6.1.21-v7l+/scripts/dtc/include-prefixes
sudo ln -s ../../../include/dt-bindings /usr/src/linux-headers-6.1.21-v7l+/scripts/dtc/include-prefixes/dt-bindings
make

Then it builds just fine.

Getting the kernel source code through other methods (like the convenient but unfortunately deprecated rpi-source) didn't have such issue.

The raspberrypi-kernel-headers deb package should be fixed to not lose the essential include-prefixes directory, so out of tree kernel modules, containing device tree overlays, compile successfully without manual fixes to kernel sources.

[XECDesign]

Closing since raspberrypi-kernel-headers is obsolete and the file seems present in current headers packages.

[gtrainavicius]

There's another similar issue with the new headers package, trying to reproduce it I sidetracked into another corner case - if running 32 bit OS on Pi 5, it's impossible to build kernel modules, as the -v8 header package can't be installed, due to its dependence on gcc-12:arm64, which is not available, as dpkg uses armhf.

Anyway, this is the issue compiling using the new linux-headers-rpi- package:

~/pisound/pisound-module $ make
make -C /lib/modules/`uname -r`/build M=/home/pi/pisound/pisound-module modules
make[1]: Entering directory '/usr/src/linux-headers-6.6.51+rpt-rpi-v7'
  CC [M]  /home/pi/pisound/pisound-module/pisound.o
  LD [M]  /home/pi/pisound/pisound-module/snd_soc_pisound.o
  DTCO    /home/pi/pisound/pisound-module/pisound.dtbo
/home/pi/pisound/pisound-module/pisound-overlay.dts:23:35: error: no include path in which to search for dt-bindings/gpio/gpio.h
   23 | #include <dt-bindings/gpio/gpio.h>
      |                                   ^
make[3]: *** [/usr/src/linux-headers-6.6.51+rpt-common-rpi/scripts/Makefile.lib:445: /home/pi/pisound/pisound-module/pisound.dtbo] Error 1
make[2]: *** [/usr/src/linux-headers-6.6.51+rpt-common-rpi/Makefile:1946: /home/pi/pisound/pisound-module] Error 2
make[1]: *** [/usr/src/linux-headers-6.6.51+rpt-common-rpi/Makefile:246: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.6.51+rpt-rpi-v7'
make: *** [Makefile:38: all] Error 2

This can be worked around by:

cd /usr/src/linux-headers-6.6.51+rpt-common-rpi/scripts
sudo mkdir dtc
cd dtc
sudo ln -s /usr/src/linux-headers-6.6.51+rpt-common-rpi/include include-prefixes
sudo ln -s /usr/bin/dtc dtc

You may reproduce these errors yourself by trying to compile the Pisound kernel module in out of tree setting, using https://github.com/BlokasLabs/pisound/tree/master/pisound-module

[XECDesign]

Newer kernel packages are based on Debian's and for the sake of being able to maintain them, I'm keeping the changes to a minimum. Unfortunately, Debian doesn't handle the case you're like to support.

I've previously reproduced this same issue in a stock Debian environment without any of our packages. i686 to amd64 works fine, but there is something different in their armhf to arm64 equivalent.

I'll see if there's anything I can do about the dtbo issue though.