I'm facing this issue: could not determine kind of name for C.BPF_MAP_TYPE_BLOOM_FILTER

[pratikjagrut]

Hi,

I'm diving into this library for the first time, and I'm pretty new when it comes to eBPF applications. While trying to build one of the apps I'm tinkering with using the libbpfgo library, I ran into this snag:

   ⨯ build failed after 2.17s error=failed to build for linux_amd64: exit status 1: # github.com/aquasecurity/libbpfgo
../../../../go/pkg/mod/github.com/aquasecurity/[email protected]/map-common.go:51:39: could not determine kind of name for C.BPF_MAP_TYPE_BLOOM_FILTER

I've got this feeling it might be a versioning or compatibility thing on my end, but I'm a bit stumped. Could someone help me figuring this out?

bpftool --version

bpftool v7.3.0
using libbpf v1.3
features:

[geyslan]

Hey @pratikjagrut, you're see the version used by bpftool. Could you check the system installed one?

For more on how to use libbpfgo see #400 (comment).

[pratikjagrut]

@geyslan I don't see libbpf_version.h file at that location.

[geyslan]

The tracee building might help you identify what's wrong:

https://github.com/aquasecurity/tracee/blob/main/Makefile#L314-L371

[ceeeeb-hao]

Why is there no output when I run the command: "grep -ir 'BPF_MAP_TYPE_BLOOM_FILTER' /usr/include/linux"?

[rscampos]

tks for you msg @ceeeeb-hao
one possibility is that your kernel don't have this const BPF_MAP_TYPE_BLOOM_FILTER defined. According with this ref it was introduced in kernel 5.16.

[ceeeeb-hao]

I also looked at this reference, but my kernel is 6.5

uname -srm
Linux 6.5.0-35-generic x86_64

[geyslan]

It should be available.

• https://elixir.bootlin.com/linux/v6.5/source/include/uapi/linux/bpf.h#L943
• https://github.com/libbpf/libbpf/blob/master/include/uapi/linux/bpf.h#L1009

But anyway, do not rely on the system libbpf, since it can mismatch the one used by libbpfgo. Try the approach of including the one available in the libbpf uapi (provided by libbpfgo), as @rscampos suggested.

Let us know. Tks for using libbpfgo.

[ceeeeb-hao]

I am also experiencing your problem, have you found a solution?

ubuntu22.04

[rscampos]

Some days ago we add this commit in our main branch, pls take a look. We add a full path (./libbpf/include/uapi) to be passed down to go build via CGO_CFLAGS. This way, even if the kernel does not have the symbol, libbpf does - as we can see in the libbpf repo.

I'd like to ask you to test it and ping me back if work or not. Tks!

[ceeeeb-hao]

I'm very sorry to say that, having seen the power of tracee, this is the first time I've used libbpfgo to write an eBPF program! May I ask if you mean this:
CC=clang CGO_CFLAGS="-I /home/chen/eBPF/libbpfgo/output/linux" CGO_LDFLAGS="/usr/lib/x86_64-linux-gnu/libbpf.a" go build -o test

Tks！

[geyslan]

Take for instance the flags from tracee building make tracee:

GOOS=linux CC=clang GOARCH=amd64 CGO_CFLAGS="-I/home/gg/code/tracee/dist/libbpf -I/home/gg/code/tracee/3rdparty/libbpf/include/uapi" CGO_LDFLAGS="-L/home/gg/code/tracee/dist/libbpf/obj -lbpf" go build

For a static building make tracee STATIC=1:

GOOS=linux CC=clang GOARCH=amd64 CGO_CFLAGS="-I/home/gg/code/tracee/dist/libbpf -I/home/gg/code/tracee/3rdparty/libbpf/include/uapi" CGO_LDFLAGS="-L/home/gg/code/tracee/dist/libbpf/obj -lbpf -lelf -lzstd -lz" go build

Notice that I'm not pointing to the system's libbpf. I suggest you do the same.

For more, check https://github.com/aquasecurity/tracee/blob/main/Makefile#L470-L489

[tsint]

Some days ago we add this commit in our main branch, pls take a look. We add a full path (./libbpf/include/uapi) to be passed down to go build via CGO_CFLAGS. This way, even if the kernel does not have the symbol, libbpf does - as we can see in the libbpf repo.

I'd like to ask you to test it and ping me back if work or not. Tks!

I regret to inform you that this commit is completely ineffective because the libbpf submodule is not included in the go module cache where libbpfgo resides, so the same error will still occur.

go build -ldflags="-extldflags=-s -w" -o tracer .
# github.com/aquasecurity/libbpfgo
/home/dc/go/pkg/mod/github.com/aquasecurity/[email protected]/map-common.go:51:39: could not determine kind of name for C.BPF_MAP_TYPE_BLOOM_FILTER
make: *** [Makefile:27: build] Error 1
dc@mint213:~/go/pkg/mod/github.com/aquasecurity/[email protected]$ ls
btf.go         buf-perf.go  builder  elf.go  go.sum   helpers_test.go  libbpfgo.c   libbpfgo.h  link.go         logger_cb.go       Makefile       map.go           map-low.go  module.go           prog-common.go  Readme.md   rwArray_test.go  tchook-common.go
buf-common.go  buf-ring.go  docs     go.mod  go.work  libbpf_cb.go     libbpfgo.go  LICENSE     link-reader.go  logger_cb_test.go  map-common.go  map-iterator.go  misc.go     module-iterator.go  prog.go         rwArray.go  selftest         tchook.go

[geyslan]

@tsint please take a look in #401 (reply in thread) above.

[tsint]

@tsint please take a look in #401 (reply in thread) above.

Thank you, that can be compiled normally, but it's still inconvenient.

[geyslan]

As libbpfgo is a wrapper of libbpf it embeds a specific version (required to make features to work). What you see as inconvenient is probably a requirement of that libbpf version itself. So as new versions are brought into libbpfgo with new features for newest kernels, some dependencies raise as well. So it is just the way it is.

As mentioned above by @rscampos, a fix was done regarding the includes that weren't set properly before (libbpfgo selftests). All flags are now generated from the embedded version. That's the way to follow to have a sane building, otherwise different includes or flags will be used (possibly from different version).

If you think in a better way to improve how libbpfgo tackles the wrapping and building for the consumer, please bring us. It will be awesome. Perhaps a PR with better instructions? Let us know.