[Letux-kernel] Compile failure on Debian bullseye

[H. Nikolaus Schaller]

Hi Stefan,


> Am 15.09.2021 um 14:07 schrieb Stefan Leichter <sle85276 at gmx.de>:
> 
> Hello Nikolaus,
> 
> after the OS upgrade from Debian buster to Debian bullseye the build of letux-kernel fails with:
> 
> make -f /home/sle/letux-kernel/scripts/Makefile.build obj=scripts/dtc
>  gcc -Wp,-MD,scripts/dtc/.yamltree.o.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89     -I /home/sle/letux-kernel/scripts/dtc/libfdt  -I ./scripts/dtc -c -o scripts/dtc/yamltree.o /home/sle/letux-kernel/scripts/dtc/yamltree.c
> /home/sle/letux-kernel/scripts/dtc/yamltree.c:9:10: fatal error: yaml.h: Datei oder Verzeichnis nicht gefunden
>    9 | #include <yaml.h>
>      |          ^~~~~~~~
> compilation terminated.
> 
> Removing the backslash in scripts/dtc/Makefile in the line:
> 
> ifeq ($(shell sh -c 'echo "\#include <yaml.h>" | ${HOSTCC} -E - 2>/dev/null >&2 && echo yes'),)
> 
> fixes the problem for Debian bullseye, but breaks the build in Debian buster. My current assumptions is that the make utility itself behaves differently for the different OS versions (buster: GNU Make 4.2.1; bullseye: GNU Make 4.3).

Hm. For me it looks more as if gcc does not find yaml.h and not a make error.
Especially the \#include has been (properly) replaced by #include in the error message.

Removing the backslash may simply make the ifeq fail. Or helps the make command not think that a comment starts.

Maybe the dev library must be reinstalled? Or some search path has changed?

https://packages.debian.org/bullseye/libyaml-dev

This yaml.h isn't part of the kernel tree but the build system.
It should be in /usr/include/yaml.h

The patched line you found above is from an attempt to check if the compiler
can find yaml.h - and (unlike the upstream version) to assume that a toolchain
comes with pkg-config.

I think we have removed that from newer kernels and I have added a fake pkg-config
script that knows what the kernel is looking for...

So you should probably git revert caaaec7d2977ac. If it works I can include that
in the next letux upgrades.

> Do you have any idea how to resolve the problem?

Not yet... I am currently in the middle of expanding my cross-toolchains
to mimick Debian jessie, stretch, buster, bullseye etc. compile environments.
Currently I am fixing glibc for buster and bullseye isn't done yet :)

But from that I know that version dependencies can be a nightmare.

BR,
Nikolaus