Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > On Tue, Feb 4, 2020 at 12:25 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: >> >> > On Mon, Feb 3, 2020 at 8:53 PM David Ahern <dsahern@xxxxxxxxx> wrote: >> >> >> >> On 2/3/20 8:41 PM, Andrii Nakryiko wrote: >> >> > On Mon, Feb 3, 2020 at 5:46 PM David Ahern <dsahern@xxxxxxxxx> wrote: >> >> >> >> >> >> On 2/3/20 5:56 PM, Andrii Nakryiko wrote: >> >> >>> Great! Just to disambiguate and make sure we are in agreement, my hope >> >> >>> here is that iproute2 can completely delegate to libbpf all the ELF >> >> >>> >> >> >> >> >> >> iproute2 needs to compile and continue working as is when libbpf is not >> >> >> available. e.g., add check in configure to define HAVE_LIBBPF and move >> >> >> the existing code and move under else branch. >> >> > >> >> > Wouldn't it be better to statically compile against libbpf in this >> >> > case and get rid a lot of BPF-related code and simplify the rest of >> >> > it? This can be easily done by using libbpf through submodule, the >> >> > same way as BCC and pahole do it. >> >> > >> >> >> >> iproute2 compiles today and runs on older distributions and older >> >> distributions with newer kernels. That needs to hold true after the move >> >> to libbpf. >> > >> > And by statically compiling against libbpf, checked out as a >> > submodule, that will still hold true, wouldn't it? Or there is some >> > complications I'm missing? Libbpf is designed to handle old kernels >> > with no problems. >> >> My plan was to use the same configure test I'm using for xdp-tools >> (where I in turn copied the structure of the configure script from >> iproute2): >> >> https://github.com/xdp-project/xdp-tools/blob/master/configure#L59 >> >> This will look for a system libbpf install and compile against it if it >> is compatible, and otherwise fall back to a statically linking against a >> git submodule. > > How will this work when build host has libbpf installed, but target > host doesn't? You'll get dynamic linker error when trying to run that > tool. That's called dependency tracking; distros have various ways of going about that :) But yeah, if you're going to do you own cross-compilation, you'd probably want to just force using the static library. > If the goal is to have a reliable tool working everywhere, and you > already support having libbpf as a submodule, why not always use > submodule's libbpf? What's the concern? Libbpf is a small library, I > don't think a binary size argument is enough reason to not do this. On > the other hand, by using libbpf from submodule, your tool is built > *and tested* with a well-known libbpf version that tool-producer > controls. I thought we already had this discussion? :) libbpf is a library like any other. Distros that package the library want the tools that use it to be dynamically linked against it so library upgrades (especially of the CVE-fixing kind) get picked up by all users. Other distros have memory and space constraints (iproute2 is shipped on OpenWrt, for instance, which is *extremely* space-constrained). And yeah, other deployments don't care and will just statically compile in the vendored version. So we'll need to support all of those use cases. -Toke
