AArch64 support broken?

[rsdy]

With redbpf, we recently started migrating to libbpf-sys from our own wrapper that preceded this project. However, our CI quickly flagged up an error on aarch64, which I think we can only address by partially reverting to generating our own bindings to certain calls.

My question is whether we're mis-using libbpf-sys, or is this a known limitation? I couldn't find other than AMD64 compatibility in the CI.

I'd be happy to dig deeper on this, just wanted to get a confirmation if you have any experience on this front.

Thanks!

[alexforster]

ARM is meant to be supported, and I regularly use this library on ARM. However, I run regenerate.sh on x86, and I definitely haven't tried to use any of the varargs bindings on ARM.

Fundamentally the issue is that bindgen is generating bindings for x86, and varargs implementations are ABI/cconv dependent. I think with this issue and with #27, there's a clear need to either pregenerate bindings specifically for different architectures and then conditionally compile in the right one, or to start generating bindings at cargo install time instead of pregenerating them.

[rsdy]

Just looking through rebuild.sh, is there a reason this can't/shouldn't be done from build.rs? Would be one way to solve this by migrating the bpf-sys build.rs here, I don't see any fundamentally different processes.

[rsdy]

@alexforster Any ideas on this? What's your preferred way of moving forward?

[anakryiko]

@rsdy I'd say let's give it a try? Are you willing to prepare a PR with these changes?

[alexforster]

As of the current release, you can now generate bindings during build time using a new feature flag called bindgen, like so:

libbpf_sys = { version = "...", features = ["bindgen"] }

Please let me know if this fixes your issue.

[jirutka]

The latest libbpf-sys does build on aarch64, at least when cross-compiling, as you can see here.

I can’t examine your log, because: Error: The log was not found. It may have been deleted based on retention settings..