On Thu, Nov 21, 2024 at 3:30 AM Quentin Monnet <qmo@xxxxxxxxxx> wrote:
>
> 2024-11-20 22:04 UTC-0800 ~ Namhyung Kim <namhyung@xxxxxxxxxx>
> > On Wed, Nov 20, 2024 at 02:25:22PM +0100, Björn Töpel wrote:
> >> Björn Töpel <bjorn@xxxxxxxxxx> writes:
> >>
> >>> From: Björn Töpel <bjorn@xxxxxxxxxxxx>
> >>>
> >>> There are a number of tools (bpftool, selftests), that require a
> >>> "bootstrap" build. Here, a bootstrap build is a build host variant of
> >>> a target. E.g., assume that you're performing a bpftool cross-build on
> >>> x86 to riscv, a bootstrap build would then be an x86 variant of
> >>> bpftool. The typical way to perform the host build variant, is to pass
> >>> "ARCH=" in a sub-make. However, if a variable has been set with a
> >>> command argument, then ordinary assignments in the makefile are
> >>> ignored.
> >>>
> >>> This side-effect results in that ARCH, and variables depending on ARCH
> >>> are not set.
> >>>
> >>> Workaround by overriding ARCH to the host arch, if ARCH is empty.
> >>>
> >>> Fixes: 8859b0da5aac ("tools/bpftool: Fix cross-build")
> >>> Signed-off-by: Björn Töpel <bjorn@xxxxxxxxxxxx>
> >
> > Reviewed-by: Namhyung Kim <namhyung@xxxxxxxxxx>
>
>
> Acked-by: Quentin Monnet <qmo@xxxxxxxxxx>
>
>
> >> Arnaldo/Palmer/Quentin:
> >>
> >> A bit unsure what tree this patch should go. It's very important for the
> >> RISC-V builds, so maybe via Palmer's RISC-V tree?
> >
> > I think it'd be best to route this through the bpf tree as it seems the
> > main target is bpftool. But given the size and the scope of the change,
> > it should be fine with perf-tools or RISC-V tree.
>
>
> The bpf tree would make sense to me as well (but I don't merge patches
> myself; let me Cc BPF maintainers).
Doesn't seem like this file is owned by anyone specific, I guess it's
fine to route it through BPF due to bpftool? Should this be bpf or
bpf-next? Also, please resend targeting the right tree, so BPF CI can
test this.
>
> Quentin
