Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > On Wed, Nov 4, 2020 at 1:16 PM Edward Cree <ecree@xxxxxxxxxxxxxx> wrote: >> >> On 04/11/2020 03:11, Alexei Starovoitov wrote: >> > The user will do 'tc -V'. Does version mean anything from bpf loading pov? >> > It's not. The user will do "ldd `which tc`" and then what? >> Is it beyond the wit of man for 'tc -V' to output somethingabout >> libbpf version? >> Other libraries seem to solve these problems all the time, I >> haven't seen anyone explain what makes libbpf so special that it >> has to be different. > > slow vger? Please see Daniel and Andrii detailed explanations. > > libbpf is not your traditional library. > Looking through the installed libraries on my devserver in /lib64/ directory > I think the closest is libbfd.so > Then think why gdb always statically links it. The distinguishing feature is the tool, not the library. For a tool that intimately depends detailed behaviour, sure it makes sense to statically link to know exactly which version you have. But for BPF, that is bpftool, not iproute2. For iproute2, libbpf serves a very simple function: load a BPF program from an object file and turn it into an fd that can be attached. For that, dynamic linking is the right thing to do so library upgrades can bring in new support without touching the tool itself. Daniel's example from upthread illustrates it: bpftool prog load | tc attach i.e., decoupling load from attach. Which is *exactly* what dynamic linking in iproute2 would mean, except using ld(1) instead of a pipe! -Toke
