[Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
Arnout Vandecappelle
arnout at mind.be
Sun Jun 19 08:20:20 PDT 2022
On 16/06/2022 10:11, Shahab Vahedi wrote:
> On 6/16/22 01:27, James Hilliard wrote:
>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
>> <buildroot at buildroot.org> wrote:
>>>
>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
>>>>
>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>>>>
>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>>>
>>> No, I don't do any sort of trickery to build bpftool on my end. The
>>> bootstrapping, if becomes available for your configuration, uses clang
>>> and only clang. I tried to explain this in v4 of the patch [1], the
>>> second paragraph of the commit message.
>>
>> I think clang/llvm support isn't going to work correctly yet since we only have
>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
>>
>> Minimum clang/llvm version for libbpf co-re is version 10:
>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
>
> You're right about the clang version, but it doesn't have anything to do
> with Buildroot's clang. The build process uses the clang that is installed
> on the host. For Debian bullseye, that is clang 11.
>
> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
Hm, that smells like we actually want to build host-clang (after updating it
to 11.1.0 of course) so that we are sure a known version of clang is used.
Possibly with a check-host-clang check to avoid building it if the installed
clang is good enough.
And we probably want a user-visible option to enable co-re then, because it's
going to be expensive to build.
Regards,
Arnout
More information about the linux-snps-arc
mailing list