[Letux-kernel] Compile failure on Debian bullseye

H. Nikolaus Schaller hns at goldelico.com
Wed Sep 15 15:35:20 CEST 2021

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?


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.


More information about the Letux-kernel mailing list