Re: [PATCH bpf-next 6/9] bpf: iterators: install libbpf headers when building

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 1, 2021 at 4:06 AM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote:
>
> 2021-09-30 13:17 UTC+0100 ~ Quentin Monnet <quentin@xxxxxxxxxxxxx>
> > 2021-09-30 12:33 UTC+0100 ~ Quentin Monnet <quentin@xxxxxxxxxxxxx>
> >> API headers from libbpf should not be accessed directly from the
> >> library's source directory. Instead, they should be exported with "make
> >> install_headers". Let's make sure that bpf/preload/iterators/Makefile
> >> installs the headers properly when building.
> >
> > CI complains when trying to build
> > kernel/bpf/preload/iterators/iterators.o. I'll look more into this.
>
> My error was in fact on the previous patch for kernel/preload/Makefile,
> where iterators.o is handled. The resulting Makefile in my v1 contained:
>
>         bpf_preload_umd-objs := iterators/iterators.o
>         bpf_preload_umd-userldlibs := $(LIBBPF_A) -lelf -lz
>
>         $(obj)/bpf_preload_umd: $(LIBBPF_A)
>
> This declares a dependency on $(LIBBPF_A) for building the final
> bpf_preload_umd target, when iterators/iterators.o is linked against the
> libraries. It does not declare the dependency for iterators/iterators.o
> itself. So when we attempt to build the object file, libbpf has not been
> compiled yet (not an issue per se), and the API headers from libbpf have
> not been installed and made available to iterators.o, causing the build
> to fail.
>
> Before this patch, there was no issue because the headers would be
> included directly from tools/lib/bpf, so they would always be present.
> I'll fix this by adding the relevant dependency, and send a v2.
>
> As a side note, I couldn't reproduce the issue locally or in the VM for
> the selftests, I'm not sure why. I struggled to get helpful logs from
> the kernel CI (kernel build in non-verbose mode), so I ended up copying
> the CI infra (running on kernel-patches/bpf on GitHub) to my own GitHub
> repository to add debug info and do other runs without re-posting every
> time to the mailing list. In case anyone else is interested, I figured I
> might share the steps:
>
> - Clone the linux repo on GitHub, push the bpf-next branch
> - Copy all files and directories from the kernel-patches/vmtest GitHub
> repo (including the .github directory) to the root of my linux repo, on
> my development branch.
> - Update the checks on "kernel-patches/bpf" repository name in
> .github/workflows/test.yaml, to avoid pulling new Linux sources and
> overwriting the files on my branch.
> - (Add as much build debug info as necessary.)
> - Push the branch to GitHub and open a PR against my own bpf-next
> branch. This should trigger the Action.
>
> Or was there a simpler way to test my set on the CI, that I ignore?

Don't know, I never tried :) But maybe Yucong (cc'ed) knows some tips
and tricks?

>
> Quentin




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux