On 06/07/2022 06:14, Andrii Nakryiko wrote: > 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. This is a different approach, but as long as static linking is made optional, this would be fine by me and should address the current use case. Quentin
