* libbfd feature autodetection
@ 2022-06-30 13:49 Roberto Sassu
2022-06-30 17:29 ` Hao Luo
0 siblings, 1 reply; 6+ messages in thread
From: Roberto Sassu @ 2022-06-30 13:49 UTC (permalink / raw)
To: bpf
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?
Thanks
Roberto
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libbfd feature autodetection
2022-06-30 13:49 libbfd feature autodetection Roberto Sassu
@ 2022-06-30 17:29 ` Hao Luo
2022-07-01 7:10 ` Roberto Sassu
0 siblings, 1 reply; 6+ messages in thread
From: Hao Luo @ 2022-06-30 17:29 UTC (permalink / raw)
To: Roberto Sassu; +Cc: bpf
Hi Roberto,
On Thu, Jun 30, 2022 at 6:55 AM Roberto Sassu <roberto.sassu@huawei.com> 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.
Hao
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: libbfd feature autodetection
2022-06-30 17:29 ` Hao Luo
@ 2022-07-01 7:10 ` Roberto Sassu
2022-07-05 14:34 ` Quentin Monnet
0 siblings, 1 reply; 6+ messages in thread
From: Roberto Sassu @ 2022-07-01 7:10 UTC (permalink / raw)
To: Hao Luo; +Cc: bpf
> From: Hao Luo [mailto:haoluo@google.com]
> Sent: Thursday, June 30, 2022 7:29 PM
> Hi Roberto,
>
> On Thu, Jun 30, 2022 at 6:55 AM Roberto Sassu <roberto.sassu@huawei.com>
> 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' \
+ FEATURE_DISPLAY='disassembler-four-args zlib libcap clang-bpf-co-re'
but I'm not sure it is the right approach.
Thanks
Roberto
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: libbfd feature autodetection
2022-07-01 7:10 ` Roberto Sassu
@ 2022-07-05 14:34 ` Quentin Monnet
2022-07-06 5:14 ` Andrii Nakryiko
0 siblings, 1 reply; 6+ messages in thread
From: Quentin Monnet @ 2022-07-05 14:34 UTC (permalink / raw)
To: Roberto Sassu, Hao Luo, Daniel Borkmann; +Cc: bpf
On 01/07/2022 08:10, Roberto Sassu wrote:
>> From: Hao Luo [mailto:haoluo@google.com]
>> Sent: Thursday, June 30, 2022 7:29 PM
>> Hi Roberto,
>>
>> On Thu, Jun 30, 2022 at 6:55 AM Roberto Sassu <roberto.sassu@huawei.com>
>> 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?
Quentin
[0]
https://lore.kernel.org/bpf/CACdoK4LTgpcuS9Sgk6F-9=cP09aACxJN4iTXJ=39OohPcBKXAg@mail.gmail.com/T/#t
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libbfd feature autodetection
2022-07-05 14:34 ` Quentin Monnet
@ 2022-07-06 5:14 ` Andrii Nakryiko
2022-07-11 9:09 ` Quentin Monnet
0 siblings, 1 reply; 6+ messages in thread
From: Andrii Nakryiko @ 2022-07-06 5:14 UTC (permalink / raw)
To: Quentin Monnet; +Cc: Roberto Sassu, Hao Luo, Daniel Borkmann, bpf
On Tue, Jul 5, 2022 at 7:46 AM Quentin Monnet <quentin@isovalent.com> wrote:
>
> On 01/07/2022 08:10, Roberto Sassu wrote:
> >> From: Hao Luo [mailto:haoluo@google.com]
> >> Sent: Thursday, June 30, 2022 7:29 PM
> >> Hi Roberto,
> >>
> >> On Thu, Jun 30, 2022 at 6:55 AM Roberto Sassu <roberto.sassu@huawei.com>
> >> 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@mail.gmail.com/T/#t
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libbfd feature autodetection
2022-07-06 5:14 ` Andrii Nakryiko
@ 2022-07-11 9:09 ` Quentin Monnet
0 siblings, 0 replies; 6+ messages in thread
From: Quentin Monnet @ 2022-07-11 9:09 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: Roberto Sassu, Hao Luo, Daniel Borkmann, bpf
On 06/07/2022 06:14, Andrii Nakryiko wrote:
> On Tue, Jul 5, 2022 at 7:46 AM Quentin Monnet <quentin@isovalent.com> wrote:
>>
>> On 01/07/2022 08:10, Roberto Sassu wrote:
>>>> From: Hao Luo [mailto:haoluo@google.com]
>>>> Sent: Thursday, June 30, 2022 7:29 PM
>>>> Hi Roberto,
>>>>
>>>> On Thu, Jun 30, 2022 at 6:55 AM Roberto Sassu <roberto.sassu@huawei.com>
>>>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-07-11 9:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-30 13:49 libbfd feature autodetection Roberto Sassu
2022-06-30 17:29 ` Hao Luo
2022-07-01 7:10 ` Roberto Sassu
2022-07-05 14:34 ` Quentin Monnet
2022-07-06 5:14 ` Andrii Nakryiko
2022-07-11 9:09 ` Quentin Monnet
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.