Rafael David Tinoco

> libbpfgo is released for specific libbpf version (as indicated by libbpfgo version name), so don't we need to test it only with that compatible version? automating will allow us...

> > know if recent changes to libbpfgo broke compatibility for previous released versions of libbpf > > why do we need this, if each release of libbpfgo supports a...

> I don't know what's the value in this. let's say we have these automated tests, and we discover that libbpfgo for libbpf 5 doesn't work with libbpf 4. Do...

This was somehow handled by: https://github.com/aquasecurity/libbpfgo/pull/28 But now we have to address the following: https://github.com/aquasecurity/libbpfgo/pull/28#issuecomment-877265305 So I would say this issue has become the issue described above.

The `Makefile` file in tracee uses `pkgconfig` for the libbpf static compilation:  libbpfgo could do the same and use: ``` // #cgo pkg-config: libelf zlib ``` to have this...

BTW, there is a generic attachment interface now, right ?  It is tied to bpf_program__attach_cgroup and some other attachments.

bpf_program__attach_cgroup PR: https://github.com/aquasecurity/libbpfgo/pull/196

@geyslan (To check the unit tests error regarding use of inexistent OS dynamic library, instead of using the static lib we build).

All libbpf/libbpfgo users relying in per CPU map feature will have to do some logic like this: 

> Adding this API would be great! Right now some projects rely on Go's [runtime library](https://pkg.go.dev/runtime#NumCPU), but I am not sure if that accounts for offline CPUs as libbpf does...