iproute2 and libbpf: vendoring on the small scale

Posted Nov 13, 2020 23:44 UTC (Fri) by pbonzini (subscriber, #60935)
Parent article: iproute2 and libbpf: vendoring on the small scale

Why not check the version of the system library and choose between a submodule and the system libbpf? That's what QEMU does for a handful of smaller, less common libraries and it works great across both older and bleeding edge distros.

to post comments

iproute2 and libbpf: vendoring on the small scale

Posted Nov 15, 2020 14:02 UTC (Sun) by Conan_Kudo (subscriber, #103240) [Link] (2 responses)

Because what QEMU does is insane! It's the worst of all worlds, because now there's an unpredictable failure mode with it switching to something that may not necessarily be adapted to the environment it's being built for. One of the reasons I hate shipping QEMU is that this brittle setup messes with my ability to build QEMU properly.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 15, 2020 14:15 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Agreed (though I've no first-hand experience with QEMU itself). What I've done for embedding is default to the internal version, but the flag to use the external version means that it required to be externally provided. This wishy-washy "what is it doing?" kind of questions about build systems are not fun to answer months down the line when you need to debug it.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 15, 2020 15:14 UTC (Sun) by pbonzini (subscriber, #60935) [Link]

I am not sure I understand. The bundled one is used as a known-good fallback, if you hate it so much you can force usage of distro libraries with configure command-line options. Most QEMU developers use the distro libraries, and so do most CI environments (not CentOS 7 of course :)) so it should not be a problem to do so.

In any case, have you reported a bug whenever you got this unpredictable failure mode?