Re: [PATCH dwarves] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Thu, Jan 21, 2021 at 12:02:53PM -0800, Andrii Nakryiko escreveu:
> On Thu, Jan 21, 2021 at 5:29 AM Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> >
> > Em Mon, Jan 04, 2021 at 10:17:36PM +0000, Luca Boccassi escreveu:
> > > On Mon, 2021-01-04 at 12:23 -0800, Andrii Nakryiko wrote:
> > > > On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org>
> > > > > > >  #include "dutil.h"
> > > > > > > +#ifdef LIBBPF_FOUND
> > > > > > > +#include <bpf/libbpf.h>
> > > > > > > +#else
> > > > > > >  #include "lib/bpf/src/libbpf.h"
> > > > > > > +#endif
> >
> > > > > > this is horrible, are you sure there is no way to make
> > > > > > <bpf/libbpf.h>
> > > > > > work for both cases?
> >
> > > > > It really is, but unfortunately I don't see other ways that are
> > > > > not just as horrible. Suggestions welcome. The only thing I can
> > > > > think of, is if libbpf used the same directory hierarchy in-tree
> > > > > as it does in the installed tree. Ie: move those headers from
> > > > > libbpf/src/foo.h to libbpf/include/bpf/foo.h. Then we would just
> > > > > have the - Ilib/bpf/include in CPPFLAGS for the embedded build
> > > > > defined in the CMake files, and the sources would only use the
> > > > > "system" includes everywhere, without ifdeffery.
> >
> > > > > Given you maintain libbpf, would that be something you'd accept?
> > > > > It's quite a common pattern for libraries to store their public
> > > > > headers in a separate directory in the git tree, after all.
> >
> > > > It's quite risky, as there are plenty of (sometimes private)
> > > > integrations that assume such a layout of libbpf, so we'll be
> > > > breaking them badly. Makefile-based projects do `make
> > > > install_headers` to put *only exported* headers into the desired
> > > > location. I'm not sure what's the best way to achieve the same with
> > > > Cmake, though.
> >
> > > > One quick and easy hack would be to put a symlink lib/include/bpf ->
> > > > lib/bpf/src into pahole repo. And add -Ilib/include to let compiler
> > > > handle <bpf/*.h> properly.
> >
> > > Sure, that works for me if it's acceptable as a solution. Sent v3 that
> > > implements it. Thanks for the suggestion.
> >
> > Andrii, can I have your Reviewed-by or Acked-by for v3?
> 
> Well, I still think it's not good and not necessary for pahole. pahole
> doesn't run under root. It's not a networking application open to the
> world either. So I don't buy security arguments in this case at all.
> So no, feel free to push this, but without my ack.
> 
> >
> > I have it in my local repo and will push publicly later today after I
> > perform tests.
> 
> While on the subject, do you have plans to release 1.20 any time soon?
> I'm holding off until 1.20 is available to sync it internally to be
> used for our kernels. Would be nice to get this off my head :)

I planed to do it as quick release, but then holidays and my vacation
got in the way, now there are some issues to solve, but I think I should
release a version and then get back to those DWARF5 and 32-bit issues
:-\

- Arnaldo