Viktor Malík

GitHub says it cannot be merged for some reason. Perhaps one more rebase is needed?

Thanks for opening this @VorpalBlade! Unfortunately, due to the way libbpf works with USDT probes, we need to link libbpf statically ☹️ The plan is to work with the upstream...

> We can try pinging the maintainer/packager to see if we can get libbpf.a packaged on Arch: https://archlinux.org/packages/core/x86_64/libbpf/ We can do that, however, IIUC, Arch is generally advising against packaging...

@VorpalBlade looking at `FindLibBpf.cmake`: https://github.com/bpftrace/bpftrace/blob/28422c98e77db924f2d2e5a2bda0367997b04547/cmake/FindLibBpf.cmake#L8-L23 The static library is searched using `LIBRARY_PATH` while the include files are searched using `CPATH`. So, I believe that you need to set both to...

That's a good point, I don't think we're relying on pkg-config in any of our custom `Find.cmake` files at the moment. Perhaps it would be good to introduce that, especially...

> There is both `-lbpf` and `/home/arvid/local/bpftrace/lib/libbpf.a` in there. That is just wrong. Agreed, there's definitely something fishy going on. Let me have a look into that.

I did some investigation and here's my understanding of things. In `src/CMakeLists.txt`, we do: https://github.com/bpftrace/bpftrace/blob/1cd4bbdd4a13dd55880f2cc638dde641fb5f8474/src/CMakeLists.txt#L72 Since we don't give full path to `libbpf.a`, CMake uses the linker to find it...

@VorpalBlade I opened #4484 which does 2 things: 1. Drops the linking against `libbpf.a` so now, the version of `libbpf.a` found by `FindBpf.cmake` should be always used. 2. Adds documentation...

> I filed an issue against the arch package for libbpf: https://gitlab.archlinux.org/archlinux/packaging/packages/libbpf/-/issues/3 > > We will have to wait and see what comes out of it. Thanks! Btw. we're currently...

> What are the changes that require static linking exactly? It would be a shame to loose useful user visible features. At the moment it's just the conversion of USDT...