Re: [Buildroot] [PATCH] linux: select BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL when needed

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello Julien,

+Peter in Cc.

On Sun, 29 Dec 2024 15:41:52 +0100
Julien Olivain <ju.o@free.fr> wrote:

> While reviewing, I quickly tested with:
> 
>      cat <<EOF >.config
>      BR2_x86_64=y
>      BR2_LINUX_KERNEL=y
>      BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
>      BR2_TOOLCHAIN_EXTERNAL=y
>      EOF
>      make olddefconfig
>      make
> 
> It failed with output:
> 
>      In file included from 
> /buildroot/output/build/linux-6.12.5/tools/objtool/include/objtool/objtool.h:13,
>                       from weak.c:10:
>      
> /buildroot/output/build/linux-6.12.5/tools/objtool/include/objtool/elf.h:10:10: 
> fatal error: gelf.h: No such file or directory
> 
> This hints to a missing BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y.

Indeed.

> Do you think we will need the same logic for other
> BR2_LINUX_KERNEL_NEEDS_HOST_* configs? It is likely that autobuilder
> will catch this kind of failures.

Yes that would be the idea.

> I was wondering if this logic will not become a bit complicated over
> time (e.g. BR2_LINUX_KERNEL_NEEDS_HOST_PYTHON3 for aarch64, ...).
> What do you think?
> 
> If you think this is OK, I'll apply this patch as is and we'll
> update those conditions in future commits, when needed.

I am not sure myself what is the right solution here. I'm trying to
avoid recurring autobuilder failures. I discussed this topic some time
ago with Peter. My idea was to do tweaks in utils/genrandconfig, but
Peter was on the opinion that we should deal with those issues directly
in the linux package, so that it doesn't just benefit the autobuilders,
but also our users.

Clearly, it's going to be a cat-and-mouse game: we discover issues in
the autobuilders and address them. This is for example the case for the
x86-64 situation you reported. But for example, I only took care of the
"latest kernel version" case, but we might have similar issues for the
CIP versions as well. My idea was to simply deal with those
progressively, improving the logic as we discover new cases.

Note that I am not 100% sure of what the best approach is. Maybe it's
one of those cases where we simply to try one approach, and decide
later if it was the right approach or not?

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot