On Wed, Feb 3, 2021 at 12:36 PM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > > On 2/3/21 12:33 PM, Andrii Nakryiko wrote: > > On Wed, Feb 3, 2021 at 12:15 PM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > >> > >> On 2/3/21 12:12 PM, Andrii Nakryiko wrote: > >>> On Wed, Feb 3, 2021 at 12:09 PM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > >>>> > >>>> On 2/3/21 11:39 AM, Andrii Nakryiko wrote: > >>>>> On Wed, Feb 3, 2021 at 9:22 AM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > >>>>>> > >>>>>> On 2/3/21 2:57 AM, Toke Høiland-Jørgensen wrote: > >>>>>>> Randy Dunlap <rdunlap@xxxxxxxxxxxxx> writes: > >>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I see this sometimes when building a kernel: (on x86_64, > >>>>>>>> with today's linux-next 20210202): > >>>>>>>> > >>>>>>>> > >>>>>>>> CONFIG_CGROUP_BPF=y > >>>>>>>> CONFIG_BPF=y > >>>>>>>> CONFIG_BPF_SYSCALL=y > >>>>>>>> CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y > >>>>>>>> CONFIG_BPF_PRELOAD=y > >>>>>>>> CONFIG_BPF_PRELOAD_UMD=m > >>>>>>>> CONFIG_HAVE_EBPF_JIT=y > >>>>>>>> > >>>>>>>> > >>>>>>>> Auto-detecting system features: > >>>>>>>> ... libelf: [ [31mOFF[m ] > >>>>>>>> ... zlib: [ [31mOFF[m ] > >>>>>>>> ... bpf: [ [31mOFF[m ] > >>>>>>>> > >>>>>>>> No libelf found > >>>>>>>> make[5]: [Makefile:287: elfdep] Error 1 (ignored) > >>>>>>>> No zlib found > >>>>>>>> make[5]: [Makefile:290: zdep] Error 1 (ignored) > >>>>>>>> BPF API too old > >>>>>>>> make[5]: [Makefile:293: bpfdep] Error 1 (ignored) > >>>>>>>> > >>>>>>>> > >>>>>>>> but pkg-config tells me: > >>>>>>>> > >>>>>>>> $ pkg-config --modversion libelf > >>>>>>>> 0.168 > >>>>>>>> $ pkg-config --libs libelf > >>>>>>>> -lelf > >>>>>>>> > >>>>>>>> > >>>>>>>> Any ideas? > >>>>>>> > >>>>>>> This usually happens because there's a stale cache of the feature > >>>>>>> detection tests lying around somewhere. Look for a 'feature' directory > >>>>>>> in whatever subdir you got that error. Just removing the feature > >>>>>>> directory usually fixes this; I've fixed a couple of places where this > >>>>>>> is not picked up by 'make clean' (see, e.g., 9d9aae53b96d ("bpf/preload: > >>>>>>> Make sure Makefile cleans up after itself, and add .gitignore")) but I > >>>>>>> wouldn't be surprised if there are still some that are broken. > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Thanks for replying. > >>>>>> > >>>>>> I removed the feature subdir and still got this build error, so I > >>>>>> removed everything in BUILDDIR/kernel/bpf/preload and rebuilt -- > >>>>>> and still got the same libelf build error. > >>>>> > >>>>> I hate the complexity of feature detection framework to the point that > >>>>> I'm willing to rip it out from libbpf's Makefile completely. I just > >>>>> spent an hour trying to understand what's going on in a very similar > >>>>> situation. Extremely frustrating. > >>>>> > >>>>> In your case, it might be feature detection triggered from > >>>>> resolve_btfids, so try removing > >>>>> $(OUTPUT)/tools/bpf/resolve_btfids/{feature/,FEATURE-DUMP.libbpf}. > >>>>> > >>>>> It seems like we don't do proper cleanup in resolve_btfids (it should > >>>>> probably call libbpf's clean as well). And it's beyond me why `make -C > >>>>> tools/build/feature clean` doesn't clean up FEATURE-DUMP.<use-case> > >>>>> file as well. > >>>> > >>>> > >>>> I don't think it's related to improper cleanup or old files/dirs > >>>> laying around. I say that because I did a full build in a new output dir. > >>>> and it still failed in the same way. > >>> > >>> If you cd tools/lib/bpf and run make there, does it detect those libraries? > >> > >> Yes: > >> > >> Auto-detecting system features: > >> ... libelf: [ on ] > >> ... zlib: [ on ] > >> ... bpf: [ on ] > >> > >> > > > > Sounds exactly like my case. I removed > > $(O)/tools/bpf/resolve_btfids/{feature/,FEATURE-DUMP.libbpf} and it > > started working. > > I already tried that with no success. > > I suppose that it could be related to how I do builds: > > make ARCH=x86_64 O=subdir -j4 all > > so subdir is a relative path, not an absolute path. so can you confirm this by specifying the absolute path to subdir? > > -- > ~Randy >