On Tue, Jul 5, 2022 at 7:46 AM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote: > > On 01/07/2022 08:10, Roberto Sassu wrote: > >> From: Hao Luo [mailto:haoluo@xxxxxxxxxx] > >> Sent: Thursday, June 30, 2022 7:29 PM > >> Hi Roberto, > >> > >> On Thu, Jun 30, 2022 at 6:55 AM Roberto Sassu <roberto.sassu@xxxxxxxxxx> > >> wrote: > >>> > >>> Hi everyone > >>> > >>> I'm testing a modified version of bpftool with the CI. > >>> > >>> Unfortunately, it does not work due to autodetection > >>> of libbfd in the build environment, but not in the virtual > >>> machine that actually executes the tests. > >>> > >>> What the proper solution should be? > >> > >> Can you elaborate by not working? do you mean bpftool doesn't build? > >> or bpftool builds, but doesn't behave as you expect when it runs. On > >> my side, when I built bpftool, libbfd was not detected, but I can > >> still bpftool successfully. > > > > Hi Hao > > > > in Github Actions, the build environment has support for > > libbfd. When bpftool is compiled, libbfd is linked to it. > > > > However, the run-time environment is different, is an ad hoc > > image made by the eBPF maintainers, which does not have > > libbfd. > > > > When a test executes bpftool, I get the following message: > > > > 2022-06-28T16:15:14.8548432Z ./bpftool_nobootstrap: error while loading shared libraries: libbfd-2.34-system.so: cannot open shared object file: No such file or directory > > > > I solved with this: > > > > diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile > > index e32a28fe8bc1..d44f4d34f046 100644 > > --- a/tools/testing/selftests/bpf/Makefile > > +++ b/tools/testing/selftests/bpf/Makefile > > @@ -242,7 +242,9 @@ $(DEFAULT_BPFTOOL): $(wildcard $(BPFTOOLDIR)/*.[ch] $(BPFTOOLDIR)/Makefile) \ > > OUTPUT=$(HOST_BUILD_DIR)/bpftool/ \ > > LIBBPF_OUTPUT=$(HOST_BUILD_DIR)/libbpf/ \ > > LIBBPF_DESTDIR=$(HOST_SCRATCH_DIR)/ \ > > - prefix= DESTDIR=$(HOST_SCRATCH_DIR)/ install-bin > > + prefix= DESTDIR=$(HOST_SCRATCH_DIR)/ install-bin \ > > + FEATURE_TESTS='disassembler-four-args zlib libcap clang-bpf-co-re' \ > > (disassembler-four-args can probably be removed too, the file using it > shouldn't be compiled if libbfd support if not present.) > > > + FEATURE_DISPLAY='disassembler-four-args zlib libcap clang-bpf-co-re' > > > > but I'm not sure it is the right approach. > > Hi Roberto, > > I don't think we have another solution for intentionally disabling > bpftool's feature at build time at the moment. For the context: I > submitted a patch last week to do just this [0], but in the end we > preferred to avoid encouraging distributions to remove features. > > But I agree it's not ideal. We shouldn't have to pass all existing > bpftool's features to the selftests Makefile. > > Daniel, what would you think of an alternative approach: instead of > having variables with obvious names like BPFTOOL_FEATURE_NO_LIBCAP, we > could maybe have a FEATURE_IGNORE in bpftool's Makefile and filter out > its contents from FEATURE_TESTS/FEATURE_DISPLAY before running the > tests? Given that features can already be edited as in the above patch, > it wouldn't change much what we can do but would be cleaner here? > Is statically linking all such dependencies into bpftool an option? If build environment has libbfd, we compile and statically link against it. Then no matter what environment bpftool runs in, we have libbfd inside. > Quentin > > [0] > https://lore.kernel.org/bpf/CACdoK4LTgpcuS9Sgk6F-9=cP09aACxJN4iTXJ=39OohPcBKXAg@xxxxxxxxxxxxxx/T/#t
